每个软件开发人员都应该知道的 9 个定律
原文地址来自于 medium：https://levelup.gitconnected.com/9-laws-that-every-software-developer-should-know-a5518bfef022
有改动，补充了一些自己的想到的信息
在软件开发中，有许多称为定律或原则的指导方针和观察。虽然这些不是在所有情况下普遍适用的严格公式，但它们提供了影响开发过程的重要框架。这些原则可以显著影响组织、团队和个人的生产力。任何参与软件的人都熟悉它们很有价值。
Brooks’s Law 布鲁克斯定律
“Adding [human resources] to a late software project makes it later.” — Fred Brooks
“投入【人力资源】到一个延期的软件项目中，只会使其交付更加延期。”
注：这句话我记得是出自《人月神话》
由于协调成本，添加到项目中的开发人员越多，并不总是能提高工作效率。
这项定律强调了在没有适当规划的情况下“投入更多人”参与已经延期项目所带来的的风险。
此外，在过于庞大的团队和由身兼数职的成员组成的小团队之间找到平衡也很重要。
Goodhart’s Law 古德哈特定律
“When a measure becomes a target, it ceases to be a good measure.” — Charles Goodhart
“当一个衡量指标成为工作目标时，它就不再是一个好的指标了。”
这意味着，一旦一个特定的指标变成了一个目标或唯一目的，人们就会开始优化他们的行为来力求达到该指标，而这往往是以牺牲这个指标本来要代表的底层含义为代价的。
真正的目标通常是难以量化的，因此，我们依赖一些不那么直接的指标，最终却将我们的工作引向了我们意想不到的方向。举几个例子：
- 真正目标：程序员的生产力，指标：代码行数
- 真正目标：需求开发速度，指标：每个 sprint（注：敏捷冲刺）中完成的 “用户故事” 数量
- 真正目标：测试的质量，指标：代码测试覆盖度
为了避免这个陷阱，我们不必放弃数据驱动的方法。可以尝试如下策略：
- 至少需要几个指标 相互参考，进而推动我们的努力
- 不断完善和重新评估之前制定的指标
- 在某些情况下，不要避免使用定性方法
Hyrum’s Law 海勒姆定律
“With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.” — Hyrum Wright
“如果 API 的用户数量足够多，你在承诺给用户什么并不重要，因为你系统的所有可观察行为都将被某人依赖。”
随着更多的用户使用你提供的 API，人们将开始依赖设计人员无意造成或无文档记录的功能。随着时间的推移，即使是微小的、未被记录的怪癖或边缘情况也会成为用户依赖的“功能”。
这使得想在不对用户造成伤害的情况下，对 API 进行更改或改进变得更加复杂。
该定律强调了随着系统的发展和演进，保持向后兼容性和管理期望的重要性和挑战。
Conway’s Law 康威定律
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” — Melvin Conway
“任何设计系统（广义定义）的组织都会产生这样的设计结果，即：其结构是组织通信结构的拷贝版本。”
软件的结构通常反映了构建它的组织结构。如果您盲目地遵循现有的团队或部门界限，您最终可能会得到与真实需求的架构或业务能力不一致的子系统划分。
“逆康威” 是康威定律的主动应用：如果我们希望我们的软件架构采用特定的形状或结构，我们应该首先组织我们的团队和通信模式，使其和我们要设计的架构相一致。
Linus’s Law 莱纳斯定律
“Given enough eyeballs, all bugs are shallow.” — Eric Raymond
“只要有足够多的人查看，所有的 bug 都是浅显易见的”
这条定律抓住了开源协作的精髓：与封闭系统相比，广泛的社区参与有助于更有效地识别和修复错误。
这个想法是，检查代码的人越多，有人注意到并解决其他人可能错过的 bug 的可能性就越大。
Hofstadter’s Law 霍夫施塔特定律
It always takes longer than you expect, even when you take into account Hofstadter’s Law. — Douglas Hofstadter
项目时长总是比你预期的要长，即使您考虑到本条定律是，结果也是如此。
霍夫施塔特定律提醒我们，在估计任务所需的时间时，尤其是在软件开发中，我们往往总是不准确。
它强调了缓冲时间和管理期望的重要性。
Kernighan’s Law 克尼汉定律
“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?” — Brian Kernighan
“每个人都知道软件调试的难度是最初编写代码时的两倍。所以，如果写代码的时候你发挥了 100% 的聪明巧思，那你要如何调试呢？（因为你的智商不会变成 200%）
编写太复杂的代码可能会对系统维护造成危险。
如果代码编写得过于复杂，调试就会变得更加困难，因为您必须先破译逻辑，然后才能修复任何问题。
编码的简单性是关键 — 从长远来看，编写清晰、可维护的代码可以更轻松地调试和改进。
Peter Principle 彼得原则
“People in a hierarchy tend to rise to ‘a level of respective incompetence.’” — Laurence Peter
“等级制度中的人往往会上升到每个人自身能力无法胜任的位置。”
成功往往伴随着代价。在许多情况下，个人根据他们的成就被提升到越来越高的职位。但是，升到了某个位置的时候，对其能力的要求可能会超出他们的实际的能力。
在软件领域，当成功的开发人员被提升到管理职位时，这种情况经常出现。
人们经常假设领导力和软技能自然会随着技术专长而增长，但事实并非总是如此。
熟练的编码员不一定具有管理和领导团队、处理领导战略需求方面的能力，这可能会导致他们的新角色面临挑战。
（这实际很好理解：如果一个人在他当前位置上是能力绰绰有余的，那么很大概率他的领导会尝试让他晋升，以负担更大的责任。但他总会升到一个自己能力不足以胜任的位置）
Pareto principle 帕累托原则
“For many outcomes, roughly 80% of consequences come from 20% of causes.” — Vilfredo Pareto
“对于许多结果，大约 80% 的后果来自 20% 的原因。”
This also emphasizes that quality outweighs quantity and that true outcomes are more important than just the volume of generated output. Prioritizing what truly moves the needle helps achieve more meaningful and sustainable results.
帕累托原则具有广泛的适用性，其关键见解之一是努力应该是有选择的。
结论是，专注于最具影响力的领域（可以产出 80% 成果的 20% 的领域）比努力过于分散更成功。
这也强调了高质量的努力大于盲目的精疲力竭，“有价值的产出” 比 “大量平庸的产出” 更重要。
优先考虑真正能推动任务向前的工作内容，有助于实现更有意义和长远影响的结果。
