在软件开发中，有非常多的参考或者言论被称之为法则。尽快他们并不是在所有情况下都能普遍适用的严格公式，但他们提供了在开发过程中非常重要的框架。这些法则对于组织、团队、个人的生产力都有显著影响。对于从事软件工作的人来说，了解熟悉这些也是非常有价值的。
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
一项指标一旦成为了目标，它将不再是一个好指标
也就是说，一旦一个特定的指标转为目标或者目的，人们就会优化他们的行为，想法设法达到这个指标，这也常常是牺牲该指标本来的意义。我们会追求那些难以量化的指标，因此，我们依赖的指标最终可能会引导我们的努力走向非预期的方向。
这可能会是：
- 代码行数 (衡量生产力)
- 每个迭代Story完成量 (衡量团队效率)
- 代码覆盖率 (衡量测试质量)
为了避免掉入该陷阱，没有必要放弃数据驱动的方式。然而，我们至少需要几个推动我们努力的指标。我们应该持续改进和重新评估这些指标，在某些情况下，也可以尝试使用定性的方式。
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用户的增长，有人开始依赖那些系统设计者未曾意图或者记录的行为。久而久之，即使是小的，未文档化的怪异行为或者极端情况，都可能会变为用户依赖的feature。在这种情况下，在不影响用户使用的大前提下，对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
众所周知，调试程序的难度是最初编写程序的2倍。所以，如果你在编写程序的时候已经竭尽所能的发挥了你的聪明才智，那么你将如何调试它呢？
编写过于复杂代码不利于后期系统的维护。如果代码极其复杂，调试会变得更加复杂。每次修复问题前，都需要重新理解逻辑。所以编码的简洁性非常重要-编写清晰、可维护的代码会使后续变更更加容易。
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%的原因。
该法则被广泛应用，即28原则，其核心见解之一就是努力应当具有选择性。其要点在于，专注于影响最大的领域-通常20%产出80%-比过分分散努力能够带来更大的成功。
这也同时强调了质量胜过数量，真正有质量的成果比仅仅产出的数量更为重要。优先处理真正能推动进展的事情，更有助于实现更加有意义和持续性的成果。
