软件工程55条黄金定律(2)有趣又有用的智慧

二、项目管理与团队协作

13. Brooks’s Law（布鲁克斯定律）

英文原文： Adding manpower to a late software project makes it later. 中文翻译： 向进度落后的软件项目增加人手会让它更落后。 详细解释： 新员工需要时间上手，消耗现有团队成员的时间进行培训和协调，这会降低整体生产力。布鲁克斯用比喻说明：”你不能通过让九个女人怀孕来在一个月内生出一个孩子。” 实践建议： 与其希望通过人力解决延期，不如调整范围或时间表。警惕”多雇些程序员”作为迟到的解决方案。

14. Dunbar’s Number（邓巴数）

英文原文： There is a cognitive limit of about 150 stable relationships one person can maintain. 中文翻译： 一个人能维持的稳定关系大约有150个的认知极限。 详细解释： 邓巴数（约150）是一个社区的大小，在这个社区中每个人都知道彼此的身份和角色。超过这个数字，我们的大脑就难以跟踪关系。在软件组织中，大于约100-150人的团队将需要更多层级或拆分为子组才能有效运作。 实践建议： 设计子团队或”团队的团队”，规模足够小以有效协作。亚马逊的”两个披萨团队”（5-10人）表明，即使在150人以内，有效的工作团队也是更小的单元。

15. The Ringelmann Effect（林格尔曼效应）

英文原文： Individual productivity decreases as group size increases. 中文翻译： 随着团队规模增加，个人生产力下降。 详细解释： 随着团队变大，协调开销增加，个人责任感降低。这是社会科学中的一个现象，最初在拉绳实验中发现：随着拉绳人数增加，每个人施加的努力减少。 实践建议： 保持团队小而精。亚马逊的”两个披萨团队”（可以用两个披萨喂饱的团队）是应对这一效应的著名方法。

16. Price’s Law（普赖斯定律）

英文原文： The square root of the total number of participants does 50% of the work. 中文翻译： 总参与者数量的平方根完成了50%的工作。 详细解释： 在一个100人的团队中，大约10人（100的平方根）完成了一半的工作。这意味着少数高绩效者贡献了不成比例的产出。 实践建议： 识别和培养高绩效者，但也要注意不要过度依赖少数关键人员（参见巴士因子）。

17. Putt’s Law（普特定律）

英文原文： Those who understand technology don’t manage it, and those who manage it don’t understand it. 中文翻译： 懂技术的人不管理它，管理它的人不懂技术。 详细解释： 这反映了技术组织中技术能力和管理责任之间的常见脱节。技术专家往往专注于技术深度，而管理者需要更广泛的视野和人际技能。 实践建议： 建立双轨职业发展路径，让技术专家可以在不成为管理者的情况下获得晋升。

18. Peter Principle（彼得原理）

英文原文： In a hierarchy, every employee tends to rise to their level of incompetence. 中文翻译： 在等级制度中，每个员工都倾向于晋升到他们无法胜任的职位。 详细解释： 有能力的人会被提拔，直到他们达到一个无法胜任的角色，然后停留在那里。这解释了为什么很多组织充斥着不称职的管理者。 实践建议： 现代科技公司 increasingly 提供双职业轨道（技术 vs 管理），以避免强迫优秀工程师进入管理岗位。

19. Bus Factor（巴士因子）

英文原文： The minimum number of team members whose loss would put the project in serious trouble. 中文翻译： 项目失去后会导致严重麻烦的最少团队成员数量。 详细解释： 巴士因子为1意味着一个人掌握关键知识；如果他们离开，项目基本上就”完蛋”了。团队应该通过分享知识、记录关键系统、代码审查和轮换职责来提高巴士因子。 实践建议： 实施结对编程、代码审查、文档编写和职责轮换，以确保知识在团队中分布。

20. Dilbert Principle（呆伯特原则）

英文原文： Companies tend to promote incompetent employees to management to limit the damage they can do. 中文翻译： 公司倾向于将无能的员工提升到管理层，以限制他们能造成的损害。 详细解释： 组织有时通过将表现不佳者提升到管理职位来处理他们，将他们从实际工作中移除。这反映了将管理视为工程师默认职业道路的根本缺陷。 实践建议： 当员工表现不佳时，尝试辅导或重新分配，如果所有方法都失败，就让他们离开，而不是让他们当老板。

21. Parkinson’s Law（帕金森定律）

英文原文： Work expands to fill the time available for its completion. 中文翻译： 工作会扩展以填满可用于完成它的时间。 详细解释： 如果一个任务被分配了两周，它会花费两周完成，即使它可以在一周内完成。这是官僚主义和自我永续的本质。 实践建议： 设定紧迫但现实的截止日期。使用敏捷方法的短冲刺（1-2周）来限制工作扩展的范围。

22. The Ninety-Ninety Rule（90-90法则）

英文原文： The first 90% of the code accounts for the first 90% of development time; the remaining 10% accounts for the other 90%. 中文翻译： 前90%的代码占用前90%的开发时间；剩下的10%占用另外90%的时间。 详细解释： 最后阶段的细节、bug修复和完善往往比预期花费更长时间。这解释了为什么软件项目经常在”几乎完成”阶段停滞数月。 实践建议： 为最后的10%预留大量缓冲时间。提前识别和解决最难的问题。

23. Hofstadter’s Law（侯世达定律）

英文原文： It always takes longer than you expect, even when you take into account Hofstadter’s Law. 中文翻译： 它总是比你预期的要长，即使你考虑了侯世达定律。 详细解释： 这突出了软件开发中时间估计的递归困难。即使你已经为意外情况预留了时间，仍然可能不够。 实践建议： 采用敏捷方法，通过短迭代和持续反馈来适应变化，而不是试图提前精确预测一切。

三、代码质量与开发实践

24. Premature Optimization（过早优化）

英文原文： Premature optimization is the root of all evil. 中文翻译： 过早优化是万恶之源。 详细解释： 在编写代码时，不要过早地优化那些可能根本不需要的部分。先让代码正确工作，然后再优化真正需要的地方。优化的代码往往更难理解和维护。 实践建议： 使用分析工具找出真正的瓶颈，而不是猜测。只在测量到性能问题时才进行优化。

25. Hyrum’s Law（休姆定律）

英文原文： With a sufficient number of API users, all observable behaviors of your system will be depended on by somebody. 中文翻译： 当API用户足够多时，你系统的所有可观察行为都会被某人依赖。 详细解释： 即使是你认为是内部实现细节的行为，也可能被用户依赖。当你改变这些”内部”行为时，可能会破坏用户的代码。 实践建议： 明确文档化API的公开契约，并尽可能将内部细节隐藏。对任何变更都要谨慎，即使是看似无害的变更。

26. The Boy Scout Rule（童子军规则）

英文原文： Leave the code better than you found it. 中文翻译： 让代码比你发现时更好。 详细解释： 不要在项目中留下腐烂的东西。这意味着花点时间重构或修复你正在处理的区域中至少一件小事。它可以包括从变量名到简化逻辑的任何事情。 实践建议： 当你修改代码时，顺便改进一下：重命名模糊的变量、提取重复代码、添加缺失的测试。

27. YAGNI – You Aren’t Gonna Need It（YAGNI原则）

英文原文： Don’t add functionality until it is necessary. 中文翻译： 不要添加不必要的功能。 详细解释： 只在实际需要时才实现功能，不要为了”可能以后会需要”而提前实现。每个添加的功能都会增加复杂性和维护成本。 实践建议： 如果你现在不需要它，就不要构建它。如果你以后确实需要，你总是可以添加它。

28. Postel’s Law（波斯特尔定律）

英文原文： Be conservative in what you do, be liberal in what you accept from others. 中文翻译： 对你所做的要保守，对你接受的要开放。 详细解释： 发送数据时要严格符合规范，接收数据时要宽容处理各种格式。这促进了系统的互操作性和稳健性。 实践建议： 在API设计中，严格遵循输出格式，但灵活处理输入，优雅地处理边缘情况。

29. Linus’s Law（林纳斯定律）

英文原文： Given enough eyeballs, all bugs are shallow. 中文翻译： 只要有足够多的眼睛，所有bug都是浅显的。 详细解释： 开源软件的优势在于，众多开发者可以审查代码，发现问题。审查的人越多，发现bug的可能性越大。 实践建议： 鼓励代码审查，无论是正式的审查流程还是结对编程。让越多人看代码，问题越早被发现。

30. Kernighan’s Law（柯尼汉定律）

英文原文： Debugging is twice as hard as writing the code in the first place. 中文翻译： 调试比一开始写代码难两倍。 详细解释： 如果你以聪明才智编写代码，那么你可能没有足够的能力来调试它。复杂的代码不仅难以编写，更难以调试。 实践建议： 编写清晰、简单的代码。如果代码太复杂以至于你自己都难以理解，调试它将是一场噩梦。

31. Testing Pyramid（测试金字塔）

英文原文： A project should have many fast unit tests, fewer integration tests, and only a small number of UI tests. 中文翻译： 项目应该有很多快速的单元测试，较少的集成测试，以及少量的UI测试。 详细解释： 这形成了一个金字塔形状，底层是大量单元测试（快速、廉价），顶层是少量端到端测试（慢、昂贵）。单元测试提供快速反馈，而端到端测试验证完整流程。 实践建议： 优先编写单元测试，然后是集成测试，最后是UI测试。避免测试金字塔倒挂（大量UI测试、少量单元测试）。

32. Pesticide Paradox（杀虫剂悖论）

英文原文： Repeatedly running the same tests becomes less effective over time. 中文翻译： 反复运行相同的测试会随时间变得不那么有效。 详细解释： 就像昆虫会对杀虫剂产生抗药性一样，代码也会对测试产生”免疫”。相同的测试无法发现新的问题。 实践建议： 定期审查和更新测试套件。添加新的测试来覆盖新功能和边缘情况。变异测试可以帮助评估测试套件的有效性。

33. Lehman’s Laws（莱曼软件演化定律）

英文原文： Software that reflects the real world must evolve, and that evolution has predictable limits. 中文翻译： 反映现实世界的软件必须演化，而这种演化有可预测的极限。 详细解释： 软件系统必须持续更新，否则就会过时。当系统演化时，其复杂性会增加，除非采取措施（如重构）来降低复杂性。 实践建议： 为演化做计划。定期进行重构以降低复杂性。接受系统终将需要重大重写或替换的事实。