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

软件工程是一门关于如何构建可靠系统的艺术。以下是55条经过时间检验的软件工程定律，涵盖系统设计、项目管理、代码质量和认知决策等多个维度。它们中的一些并不只适用于软件工程中，而是有着更广泛的适用范围。

一、系统设计与架构

1. 1. Conway’s Law（康威定律）
2. 2. Gall’s Law（高尔定律）
3. 3. The Law of Leaky Abstractions（抽象泄露定律）
4. 4. CAP Theorem（CAP定理）
5. 5. Second-System Effect（第二系统效应）
6. 6. Fallacies of Distributed Computing（分布式计算的谬误）
7. 7. Broken Windows Theory（破窗理论）
8. 8. Technical Debt（技术债务）
9. 9. DRY – Don’t Repeat Yourself（DRY原则）
10. 10. KISS – Keep It Simple, Stupid（KISS原则）
11. 11. SOLID Principles（SOLID原则）
12. 12. Law of Demeter（迪米特法则）

二、项目管理与团队协作

1. 13. Brooks’s Law（布鲁克斯定律）
2. 14. Dunbar’s Number（邓巴数）
3. 15. The Ringelmann Effect（林格尔曼效应）
4. 16. Price’s Law（普赖斯定律）
5. 17. Putt’s Law（普特定律）
6. 18. Peter Principle（彼得原理）
7. 19. Bus Factor（巴士因子）
8. 20. Dilbert Principle（呆伯特原则）
9. 21. Parkinson’s Law（帕金森定律）
10. 22. The Ninety-Ninety Rule（90-90法则）
11. 23. Hofstadter’s Law（侯世达定律）

三、代码质量与开发实践

1. 24. Premature Optimization（过早优化）
2. 25. Hyrum’s Law（休姆定律）
3. 26. The Boy Scout Rule（童子军规则）
4. 27. YAGNI – You Aren’t Gonna Need It（YAGNI原则）
5. 28. Postel’s Law（波斯特尔定律）
6. 29. Linus’s Law（林纳斯定律）
7. 30. Kernighan’s Law（柯尼汉定律）
8. 31. Testing Pyramid（测试金字塔）
9. 32. Pesticide Paradox（杀虫剂悖论）
10. 33. Lehman’s Laws（莱曼软件演化定律）

四、认知偏差与决策

1. 34. Goodhart’s Law（古德哈特定律）
2. 35. Gilb’s Law（吉尔布定律）
3. 36. Dunning-Kruger Effect（邓宁-克鲁格效应）
4. 37. Hanlon’s Razor（汉隆剃刀）
5. 38. Occam’s Razor（奥卡姆剃刀）
6. 39. Sunk Cost Fallacy（沉没成本谬误）
7. 40. The Map Is Not the Territory（地图不是领土）
8. 41. Confirmation Bias（确认偏误）
9. 42. First Principles Thinking（第一性原理思维）
10. 43. Inversion（逆向思维）
11. 44. Pareto Principle（帕累托原则/80-20法则）

五、技术趋势与网络效应

1. 45. Zawinski’s Law（扎温斯基定律）
2. 46. Sturgeon’s Law（斯特金定律）
3. 47. Amdahl’s Law（阿姆达尔定律）
4. 48. Gustafson’s Law（古斯塔夫森定律）
5. 49. Metcalfe’s Law（梅特卡夫定律）
6. 50. The Hype Cycle & Amara’s Law（炒作周期与阿玛拉定律）
7. 51. The Lindy Effect（林迪效应）

六、其他重要定律

1. 52. Law of Unintended Consequences（意外后果定律）
2. 53. Murphy’s Law（墨菲定律）
3. 54. Tesler’s Law（特斯勒定律/复杂性守恒）
4. 55. Cunningham’s Law（坎宁安定律）

一、系统设计与架构

01. Conway’s Law（康威定律）

英文原文： Organizations design systems that mirror their own communication structure. 中文翻译： 组织设计系统时会复制自身的沟通结构。 详细解释： 康威定律指出软件系统反映了构建它们的组织的沟通结构。如果你的公司按部门划分（前端、后端、数据库），你很可能会得到一个三层架构。小型分布式团队倾向于产生模块化服务架构，而大型同地团队倾向于构建单体应用。 实践建议： 要实现期望的软件架构（如微服务），你可能需要相应地重组团队，因为团队按照他们的沟通路径构建软件。亚马逊的”两个披萨团队”就是一个典型例子，每个团队拥有特定的服务。

02. Gall’s Law（高尔定律）

英文原文： A complex system that works is invariably found to have evolved from a simple system that worked. 中文翻译： 一个能工作的复杂系统总是由一个能工作的简单系统演化而来。 详细解释： 不要从头构建复杂系统。相反，先做一个能工作的简单版本，然后迭代添加复杂性。这种方法可以作为实验和创新的发射台。成功的大型系统通常是有机成长的。一个完全从零开始设计的复杂系统通常会失败，因为你无法预见所有交互。 实践建议： 创建最小可行产品（MVP），一个简单工作的核心，然后成长它，而不是大爆炸式的方法。

03. The Law of Leaky Abstractions（抽象泄露定律）

英文原文： All non-trivial abstractions, to some degree, are leaky. 中文翻译： 所有非平凡的抽象，在某种程度上都是泄露的。 详细解释： 无论你设计得多好，抽象（库、框架等）都有依赖于内部细节的边缘情况。开发者应该明白，使用高级工具并不能免除他们了解底层发生情况的责任。”泄露”意味着你可能会遇到性能问题、bug或行为，迫使你考虑抽象所基于的底层系统。 实践建议： 在创建抽象时，努力最小化泄露并记录可能破坏的情况。当抽象失败时，了解底层原理会帮助你快速定位问题。

04. CAP Theorem（CAP定理）

英文原文： A distributed system can guarantee only two of: consistency, availability, and partition tolerance. 中文翻译： 分布式系统只能保证一致性、可用性和分区容错性中的两个。 详细解释： 分布式系统只能同时保证以下三个中的两个：一致性（所有节点看到相同的数据）、可用性（每个请求都收到响应）和分区容错性（系统在网络故障时继续运行）。由于网络分区在实践中不可避免，系统必须选择一致性或可用性。 实践建议： MongoDB倾向于一致性（CP），在分区期间阻塞写入以保持所有副本同步。Cassandra倾向于可用性（AP），即使在副本短暂不一致时也能继续服务查询。

05. Second-System Effect（第二系统效应）

英文原文： Small, successful systems tend to be followed by overengineered, bloated replacements. 

中文翻译： 小而成功的系统之后往往会出现过度工程化的臃肿替代品。 

详细解释： 第一个系统因约束或经验不足而保持精简。设计其继任者时，有倾向将所有最初遗漏的功能都包含进来，导致功能膨胀。过度自信也起作用——成功过一次后，团队觉得可以应对更多，低估了复杂性。 实践建议： 警惕”这次我们会做对”的心态。增量改进通常比完全重写更好。

06. Fallacies of Distributed Computing（分布式计算的谬误）

英文原文： A set of eight false assumptions that new distributed system designers often make. 

中文翻译： 新手分布式系统设计者常犯的八种错误假设。 

详细解释： 网络会丢消息、引入延迟、吞吐量有限、可能不安全。八种谬误包括：网络可靠、延迟为零、带宽无限、网络是安全的、拓扑不变、只有一个管理员、传输成本为零、网络是同构的。 

实践建议： 使用缓存（带宽/延迟不完美）、构建冗余（网络不可靠）、处理动态成员（拓扑变化）。

07. Broken Windows Theory（破窗理论）

英文原文： Don’t leave broken windows (bad designs, wrong decisions, or poor code) unrepaired. 中文翻译： 不要留下破损的窗户（糟糕的设计、错误的决策或劣质代码）不修复。 详细解释： 如果忽视小的bug和糟糕的代码风格，人们会认为质量不重要，从而提交更混乱的代码。维护良好的代码库会鼓励工程师保持清洁，而混乱的代码库则会鼓励走捷径和进一步退化。 

实践建议： 在问题还小时就修复它们。重构破坏性代码，更新过时的文档，防止代码健康的螺旋式下降。

08. Technical Debt（技术债务）

英文原文： Technical Debt is everything that slows us down when developing software. 

中文翻译： 所有拖慢我们软件开发速度的东西。 

详细解释： 当我们在代码中走捷径时，我们从未来借时间。这带来即时的好处，但你欠下本金（修复的工作）加利息。如果不偿还，每分钟花在脏代码、bug和变通方案上的时间都是债务的利息。并非所有技术债务都是坏的——有时为了市场时机或原型设计是必要的。 

实践建议： 定期偿还技术债务：重构代码、添加缺失的测试、改进设计。

09. DRY – Don’t Repeat Yourself（DRY原则）

英文原文： Every piece of knowledge must have a single, unambiguous, authoritative representation. 

中文翻译： 每一个知识片段都必须有一个单一的、明确的、权威的表示。 

详细解释： DRY原则是关于避免代码中知识的重复。如果相同的想法或逻辑出现在多个地方，这就是重构的信号。当需求变化时，你应该只在一个地方更新逻辑。重复代码会增加不一致性和bug的风险。 

实践建议： 但DRY是关于意图重复，而不仅仅是代码重复。两段代码可能看起来相同但服务于不同的目的。

10. KISS – Keep It Simple, Stupid（KISS原则）

英文原文： Designs and systems should be as simple as possible. 中文翻译： 设计和系统应该尽可能简单。 详细解释： KISS主要指避免解决方案设计中的复杂性。满足需求且设计简单的解决方案比复杂的更好。编码的代码更容易理解和调试。对你自己的未来自我来说，理解和修复也更容易。 实践建议： 聪明的代码可能一开始看起来令人印象深刻，但通常会掩盖问题。解决方案应该尽可能简单。

11. SOLID Principles（SOLID原则）

英文原文： Five main guidelines that enhance software design, making code more maintainable and scalable. 中文翻译： 五条增强软件设计的主要准则，使代码更可维护和可扩展。 

详细解释：

• • Single Responsibility（单一职责）：一个类只负责一个功能
• • Open/Closed（开闭原则）：对扩展开放，对修改关闭
• • Liskov Substitution（里氏替换）：子类必须能替换父类
• • Interface Segregation（接口隔离）：不强制依赖不用的接口
• • Dependency Inversion（依赖倒置）：依赖抽象而非具体实现

12. Law of Demeter（迪米特法则）

英文原文： An object should only interact with its immediate friends, not strangers. 中文翻译： 一个对象应该只与它的直接朋友交互，不与陌生人交互。 详细解释： 对象应该只调用以下对象的方法：自身、其直接组件、其函数参数、或它创建的对象。它不应该通过导航一个对象来到达另一个对象（”不要和陌生人说话”）。 实践建议： 这通常会导致添加包装方法或委托。虽然这可能会增加方法数量，但结果是更清晰的交互。

本文整理自 Laws of Software Engineering 原文链接: https://lawsofsoftwareengineering.com/ 整理时间: 2026年4月