如果你是一名开发人员, 那么你可能会在团队中经历过一些事情……
- 有时候, 你很难对代码进行少量更改。
- 由于你对代码进行了更改, 因此破坏了软件的功能。
- 你在修复另一个漏洞时引入了一个新的错误。
- 你实现了一些不必要的代码, 这些代码在你的应用程序中不是必需的。
- 由于代码复杂, 你很难添加新功能。
- 永不出货的产品
- 你从应用程序中删除了一些代码, 并从头开始重写了它们。
如果以上任何一种说法对你都适用, 那么你可能希望在这些情况下哭泣。
上述所有问题都是大多数开发团队中常见的问题。
造成开发人员项目破坏的因素很多。你不会立即看到效果, 也许一年或更长时间都不会看到效果。在大多数情况下, 我们不会关注这些小因素, 并且我们认为这不会严重影响我们的项目, 但是这些小因素可能会长期损害你的项目。
在开发中, 当你开始进行项目工作时, 一切似乎都正常, 但是随着时间的流逝, 项目的复杂性会增加, 并且你开始忽略应用程序中的一些小因素。后来, 这些小因素造成了大问题, 你自己的项目对你而言变成了噩梦和恐怖故事。
如果你了解一些软件的基本定律, 并且了解了出色的开发人员的思维方式, 就可以避免这些问题。我们将详细讨论该主题, 它将帮助你在开发过程中做出正确的决定。你将能够使你的软件易于管理且尽可能简单。
1.了解软件的用途
在开始进行项目之前, 请了解软件的主要目标或目的。你的软件的目的是什么？……。帮助人们。如果你环顾四周, 你会发现你在日常生活中使用的许多应用程序, 所有这些应用程序都有一个共同的目的…。来帮助人们。
该软件的目的不是炫耀你的智能。 -Max Kanat-Alexander, 代码简单
永远记住上面写的报价。优秀的开发人员从来没有考虑过软件的目的是炫耀他们在编写项目代码时多么聪明。如果你不了解该软件的用途, 则将构建一个复杂的系统或一个错误的应用程序。不良的应用程序并不能给人们带来太大帮助。
当你开始进行项目时, 请向自己问一个问题"我们能帮你什么吗？", 然后答案将帮助你了解应用程序的主要目标。此外, 通过这种方式, 你将能够在应用程序中优先处理功能请求。
2.了解软件设计的目标
仅需记住两件事, 即可了解软件设计的目标。你的设计应尽可能简单, 并且对其他用户有帮助。
在软件开发中, 很多时候很难创建或修改某件东西, 开发人员将注意力转移到使事情"正常运行"上, 而他们将更少的时间花费在帮助用户上。每个程序员都是设计师, 而作为开发人员, 你需要了解软件设计的目标。
软件设计的目的是使开发人员的工作尽可能轻松。这样, 开发人员将能够专注于应用程序中其他重要的事情。了解软件设计的目标将帮助你创建对用户有帮助的应用程序, 并且该应用程序将持续很长时间。
3.了解你的系统和工作
在开始进行项目之前, 请确保你完全了解自己的 系统, 你的行为, 功能, 功能和工具。如果你不了解自己的系统, 并且系统无法正常运行, 那么你的工作将变得更加困难, 并且将朝着构建复杂的系统的方向迈进。
而且, 误解会导致进一步的误解, 并且在应用程序中会变成恶性循环。这些误解只会增加系统的复杂性, 而这种复杂性将来可能会严重损害你的项目。如果开发人员正确地理解了他们的系统, 他们还将了解他们在应用程序中需要做什么。
优秀的开发人员知道他们在应用程序中需要做什么, 而糟糕的开发人员仅仅因为不了解系统及其正常工作, 就不知道自己在应用程序中正在做什么。
4.遵循简单性
作为开发人员, 如果你需要处理复杂的代码而又不了解应用程序中特定代码的作用, 你会感觉如何。如果你不了解代码库中已经实现的代码, 你将如何继续执行它并执行自己的任务？当然, 这对任何开发人员来说都是令人沮丧的, 并且使他们很难在这类系统上工作。
作为开发人员, 你的目标应该是减少系统的复杂性, 而不是创建系统, 而不是增加系统。如果你认为编写复杂的代码使你成为一个聪明而又聪明的开发人员, 那你就完全错了。这是错误的心态, 在软件开发中绝对不要犯此错误。优秀的开发人员始终将代码保持尽可能简单, 以便其他开发人员可以理解它并进行处理。
请记住, 在软件开发中, 复杂性与智能无关, 而简单则与智能无关。代码的简单性表明你是一名优秀的开发人员, 而不是复杂性。
一个好的开发人员会创建易于理解和易于更改的事物。请记住, 对于你的代码不熟悉的开发人员, 他们必须学习有关它的所有知识。因此, 在编写一些复杂的代码之前, 只需对自己问一个问题"我是否希望其他开发人员理解该代码, 感到高兴并继续使用它, 还是希望他们感到困惑和沮丧？"
现在, 你可能会问自己一个问题……"你必须要多么简单？"
答案是…s温顺, 愚蠢。
5.控制复杂性
在软件开发中, 大多数项目由于系统的复杂性而失败。你从一个简单的项目开始, 但是随着时间的推移, 你会继续向其中添加功能, 而几个月后, 当你回顾自己的代码时, 你会意识到你已经编写了许多不必要的代码, 并且构建了更加复杂的代码系统。你意识到自己无缘无故地在软件中扩展了一些功能。
你的问题不止于此。由于复杂性, 你成为系统中许多错误的受害者。你开始修复这些错误时没有意识到它很严重影响应用程序的其他部分。修复一个错误就是引入一个新错误和现在你意识到即使在系统上进行很小的更改也很难。
最后, 当你意识到这很耗时并且现在一切都已失控。 ÿ你做出修复所有问题的最终决定：从头开始重写代码.
上面的故事是最常见的恐怖之一故事在编程中。大部分的开发商面对它并成为受害人它的。所以题是……如何避免这个问题？
首先, 你需要了解软件的确切用途。第二, 你需要在编写的每段代码中都尽可能简单。第三, 当请求新功能时, 评估根据你的应用目的对其进行质疑。
另外, 开发人员, 你的行为应能抗拒变化。在不需要之前, 请勿进行任何更改或添加某些功能。你将防止自己在应用程序中编写不必要的代码。
6.保养
大多数时候, 开发人员不注意代码的维护。他们专注于产品的快速编码和快速发货, 而忽略了代码维护的重要性。无论你构建的是小型应用程序还是大型应用程序, 都将始终需要对应用程序进行一些更改。
你在应用程序中构建的每个功能以及在应用程序中进行的每个更改都需要保养。所以请记住, 作为开发人员, 你的工作不仅是在应用程序中实现功能或更改。你还需要注意未来维护代码或更改应用程序。
简单性和复杂性, 这两个因素主要负责代码维护。你为任何软件编写的代码越简单, 维护它就越容易。复杂的系统需要更多的维护工作。
减少维护工作比减少实施工作更为重要。 -代码简化的Max Kanat-Alexander
7.保持一致
系统的简单性在很大程度上取决于一致性。始终很难理解不一致的代码, 并且开发人员需要在学习和理解它上付出更多的努力。
如果你遵循一种在某处做某事的方法, 则遵循类似的方法在每个地方。例如：在你的应用程序中, 如果你将变量命名为" variableOne", 则所有变量均应采用这种方式命名(variableTwo, variableThree等, 而不是variable_three)。
8.优先排序
在你的编程旅程中, 对于某些事情或特定问题, 你将有很多选择。在那里, 你必须做出选择最佳选择的决定。现在的问题是……如何对你的软件做出决定？如何确定事物的优先级, 需要考虑哪些因素才能做出更好的决策。
在书里代码简单, 用一些方程很好地解释了……
- 变更的可取性(D)：衡量你希望系统中发生的变更(多少？)
- 变化值(V)：变更提供的价值度量(多少？)。它对用户有多大帮助？
- 进行更改所需的努力(E)：测量 完成此更改所需要做的工作(多少？)
下面是优先考虑事物并做出决定的等式。
D=V/E任何更改的可取性与更改的值成正比, 而与进行更改所涉及的工作成反比。 —代码简单
上一行将帮助你做出更好的决定。选择需要较少努力但带来很多价值的选项。忽略那些需要更多努力但带来一点价值的选项。
9.解决问题
要解决该问题, 你需要首先了解该问题。你应该确切地询问要求什么, 并确保清除所有混乱之处。
你可以按照费曼技术了解一个难题。在这种技术中, 你需要用简单的术语向他人解释你的问题。
如果你无法简单地解释某些内容, 那么你将无法理解。理查德·费曼(Richard Feynman)
了解问题后, 制定计划并采取措施。
审视整个大问题可能会吓到你, 因此最好将问题划分为各种小任务。划分任务后, 一个一个地解决每个子问题, 然后将其合并以获得完整的解决方案。
10.不要追求太多完美
大多数开发人员常犯的错误之一是, 他们希望使应用程序中的所有内容变得过于完美。他们希望完美地构建每个功能, 因此, 他们倾向于从一开始就详细计划所有事情。大多数时候, 他们的工作重点转移到仅使事情变得完美, 而不是解决问题和帮助人们使用其软件。
"完美是善的敌人。" —伏尔泰
当开发人员开始进行项目开发时, 他们开始考虑要在系统中构建的每个小细节或功能。每当他们做出一些假设和预测时, 他们都会对自己问一个问题：如果"。他们从未来的角度考虑他们的软件, 并据此预测一切。
对于任何开发人员而言, 从未来的角度对项目的想象力成为构建一切都太完美的主要原因。开发人员认为他们的项目必须像他们想象的那样完美。开发人员不关注某些事情, 但是追求太多的完善可能对他们有害。作为开发人员, 如果你在项目中追求太多的完美, 那么以下是你以后可能发生的事情……
- 你将编写不必要的代码, 并从未来的角度进行思考。
- 由于不必要的代码, 复杂度将增加。
- 你太普通了。
- 你将错过最后期限。
- 项目的复杂性将在软件中引入许多错误。
任何开发人员都不想面对以上所有问题。因此, 作为开发人员, 在这种情况下应采取的行动...
从小处着手, 加以改进, 然后再扩大。
让我们考虑在系统中实现计算器的示例...
- 制定计划以建立一个只做加法运算, 没有别的。
- 制定并实施计划。
- 在现有系统中进行改进, 以便你可以添加其他操作。
- 现在制定减法计划, 并重复步骤2和3。
- 制定乘法计划并重复步骤2和3。
- 制定划分计划并重复步骤2和3。
不要在软件中追求太多的完善。足够好就可以了。
11.预测
从未来的角度考虑, 我们编写了许多不必要的代码, 并且在应用程序中变得太通用了, 这是不好的。在软件开发中, 你无法预测未来, 因此, 无论你的解决方案多么通用, 你都无法实现未来的实际需求。
在大多数情况下, 不需要这些要求的未来, 你最终会写不必要代码并增加系统的复杂性。更多复杂的系统成为开发人员的负担, 也可能破坏你的应用程序。
所以最好不要预测 的未来并实施一些不需要的东西。只知道你现在需要的通用性。
12.不要重新发明轮子。
如果已经存在, 请不要实施。
许多开发人员花费时间来构建或创建门户网站上已经存在的内容。这是常见的错误之一, 只会浪费开发人员的宝贵时间。他们可以花时间在其他更重要的事情上, 而不必重新发明轮子。
现在的问题是……何时可以重新发明轮子吗？下面是答案…
- 实施尚不存在的东西。
- 如果所有现有的"轮子"建立不好技术并且无法满足你的需求。
- 现有"车轮"缺乏维护
13.抵抗
对更改请求说不, 直到或除非不重要为止。如果你对每个请求都说"是", 并且开始处理每个请求, 那么你将犯错。
你将在应用程序中添加更多代码, 这将增加系统的复杂性。因此, 最好不要在软件中进行不必要的更改。
现在的问题是……我们需要在软件中实现哪个变更请求？
回去, 记住你的软件用途, 和中的简单方程式的优先排序部分。
14.自动化重复性任务
其中最...之一 令人沮丧 软件开发中的事物正在执行某些重复性任务。重复的任务只会浪费你的额外时间, 而一次又一次地工作是很愚蠢的事情。当你意识到自己正在做某事时, 请一次又一次地设置它们, 使其自动化并忘记它们。如果你可以自动执行某项操作, 并且节省了宝贵的时间, 则可以对其进行自动化。
15.代码测量
不要根据代码行数来衡量软件的质量。编写更多行代码并不能使你成为一名出色的开发人员。如果你认为一千行代码始终是大型软件或应用程序的标志, 那么并非总是如此。在大多数情况下, 软件设计会出问题。
如果你仔细注意, 那么可以用一小段代码解决很多问题。应用程序中的大多数简单解决方案不需要大量代码。更少的代码使你的应用程序更简单, 但你还需要记住, 你并不会编写很少的代码行。
如果你专注于编写很少的代码行, 那么你可能会陷入编写其他开发人员难以理解的聪明代码的陷阱。因此, 你需要找到一个平衡点, 只需要编写大量易于理解和阅读的代码即可。
16.生产力
许多开发人员通过在应用程序中编写的代码行数来衡量他们的生产力。请记住, 在软件开发中, 如果从代码库中抛出不必要的代码, 则可以提高生产率。
你的目标不应是编写更多的代码和增加复杂性。你应该考虑删除不必要的代码并使事情尽可能简单。这条黄金法则不仅会提高你的工作效率, 还将提高其他开发人员的工作效率。
17.测试代码的每个部分
在软件开发中, 始终在实施的早期阶段添加日志记录。你将节省大量时间, 并且可以轻松地在应用程序中发现问题。
现在考虑你在应用程序中编写了一个简单的if-else块的情况。你将输入提供给软件, 然后输入if块内。你对其进行测试, 然后将代码提交给源代码管理。从你的角度来看已经完成了, 但是else块又如何呢？当你的软件交付生产时, 它将产生一个错误。
为避免此类问题, 请正确测试你的代码。 Ë至少对所有新行执行一次, 并测试每个部分, 而不是最后测试整个应用程序。实施应用程序时, 请继续对其进行测试。你可能会认为测试每个部分很耗时, 但是如果你真的想避免自己遇到大麻烦, 并且想节省宝贵的时间, 那么一定要在实施过程中测试应用程序的每个部分。
当你在应用程序中发现错误时, 请对其进行重现。不要猜测错误的来源并根据你的假设进行修复。亲眼看到时应用修补程序。将其提交到源代码管理之前, 请务必可靠并确保已正确测试你的代码。
18.不要小看
一切花费的时间比你想象的要长。
这是你在软件开发中应记住的最重要的黄金规则之一。
大多数开发人员在软件开发中犯了一个常见错误。他们低估了开发少量代码或实现功能所需的时间和精力。如果你低估了这两个方面, 那么你将错过最后期限。
为了正确估算, 你可以打破大任务变成小任务。较小的任务很容易估计, 甚至如果你猜错了, 那么你自己的估算值与正确的估算值之间只会有细微的差别。这不会严重影响你的软件。
19.文档和评论
当大多数开发人员对一段代码发表评论时, 他们认为他们需要提及"代码在做什么".错了如果你需要提及这一点, 那么你的代码肯定是不可读的, 并且需要使其变得更容易和更简单。
当你无法简化代码时, 请写注释并解释其复杂性。评论的真正目的是提及"为什么你没有做"什么"的 代码正在做。评论on该代码可帮助其他程序员继续使用该软件并对其进行开发。如果你不这样做, 那么开发人员可以从代码中删除重要部分。
你还需要注意文档。你的软件的体系结构, 模块及其组件应在文档中提及。文档有助于你查看软件的高级概况, 如果新开发人员了解软件的完整体系结构, 则可以更轻松地进行工作。如果他们对应用程序的不同部分或完整体系结构一无所知, 他们可能会犯错。
20.不要成为超人
很多时候, 我们高估了完成某些任务的潜力。对自己的潜力充满信心是件好事, 但过分自信也不好。很多时候, 辞职比成为超人和表明自己可以做某事更好。除了使事情变得完美和完成任务之外, 你还会犯一些大错, 并弄糟一切。
假设你估计一项任务可以在两个小时内完成。你开始研究它已经四个小时了, 但你仍然仅完成了四分之一。在这里, 你需要退出任务, 而不要认为"我不应该放弃, 我已经花了四个小时"
你下定决心要完成任务, 但有时你确实需要进行实际思考并向自己提出问题："以短暂的损失退出任务会更好, 还是最终继续犯一个大失误会更好？"
不要沉迷。知道何时该退出, 不要犹豫寻求帮助。
