law-sofsoftware-engineering
- S：在学习和实践“law-sofsoftware-engineering”时，需要建立统一的概念和问题边界。
- C：相关概念、实现机制和工程取舍容易混在一起，导致只记住结论而无法判断适用条件。
- Q：“law-sofsoftware-engineering”要解决什么问题？它的核心抽象、工作机制和边界分别是什么？
- A：本文围绕“law-sofsoftware-engineering”整理核心概念、关键机制和工程实践，并明确其适用边界。
https://lawsofsoftwareengineering.com
S: 软件工程中存在大量经验法则和定律，散落在各种书籍和文章中。
C: 不同定律适用于不同层面（架构、团队、质量、决策等），容易混淆或遗漏。
Q: 如何系统地理解和运用这些软件工程定律？
A: 按类别梳理，理解每条定律的核心含义，在实际工作中有意识地识别和应用。
Architecture 架构
| 定律 |
中文名 |
核心含义 |
| Conway's Law |
康威定律 |
组织的系统设计会映射其沟通结构 |
| Hyrum's Law |
海勒姆定律 |
API 用户足够多时，系统的所有可观测行为都会被依赖 |
| Gall's Law |
盖尔定律 |
能运行的复杂系统必然是从能运行的简单系统演化而来 |
| Law of Leaky Abstractions |
抽象泄漏定律 |
所有非平凡的抽象都会在某种程度上泄漏 |
| Tesler's Law (Conservation of Complexity) |
泰斯勒定律（复杂度守恒） |
每个应用都有不可消除的固有复杂度，只能转移，不能消除 |
| CAP Theorem |
CAP 定理 |
分布式系统只能同时保证一致性、可用性、分区容错性中的两个 |
| Second-System Effect |
第二系统效应 |
成功的小系统之后，往往是过度工程化的臃肿替代品 |
| Fallacies of Distributed Computing |
分布式计算谬误 |
分布式系统设计者常犯的八个错误假设（网络可靠、零延迟等） |
| Law of Unintended Consequences |
意外后果定律 |
改变复杂系统时，要预期意外副作用 |
| Zawinski's Law |
扎温斯基定律 |
每个程序都会膨胀到能读邮件为止（功能蔓延） |
Design 设计
| 定律 |
中文名 |
核心含义 |
| YAGNI |
你不会需要它 |
在需要之前不要添加功能 |
| DRY |
不要重复自己 |
每条知识在系统中应有唯一、明确、权威的表示 |
| KISS |
保持简单 |
设计和系统应尽可能简单 |
| SOLID Principles |
SOLID 原则 |
五条提升软件设计质量的指导原则（SRP/OCP/LSP/ISP/DIP） |
| Law of Demeter |
迪米特法则 |
对象只应与直接朋友交互，不要和陌生人说话 |
| Principle of Least Astonishment |
最小惊讶原则 |
软件的行为应让用户和开发者最少感到意外 |
Teams 团队
| 定律 |
中文名 |
核心含义 |
| Brooks's Law |
布鲁克斯定律 |
向延期项目增加人手只会让它更晚交付 |
| Dunbar's Number |
邓巴数 |
一个人能维持的稳定关系上限约为 150 人 |
| Ringelmann Effect |
林格尔曼效应 |
团队规模增大时，个体生产力下降（社会惰化） |
| Price's Law |
普莱斯定律 |
总参与者的平方根完成了 50% 的工作 |
| Putt's Law |
帕特定律 |
懂技术的人不管理技术，管理技术的人不懂技术 |
| Peter Principle |
彼得原理 |
层级组织中，每个人都会晋升到其不胜任的位置 |
| Bus Factor |
巴士因子 |
最少几个关键成员离开会导致项目陷入困境 |
| Dilbert Principle |
呆伯特原理 |
公司倾向于把不称职的员工提拔到管理层以减少危害 |
Planning 计划
| 定律 |
中文名 |
核心含义 |
| Premature Optimization (Knuth) |
过早优化（Knuth） |
过早优化是万恶之源 |
| Parkinson's Law |
帕金森定律 |
工作会膨胀以填满所有可用时间 |
| Ninety-Ninety Rule |
九十-九十法则 |
前 90% 代码花前 90% 时间；剩下 10% 再花 90% 时间 |
| Hofstadter's Law |
侯世达定律 |
事情总比预期花更长时间，即使考虑了 Hofstadter 定律 |
| Goodhart's Law |
古德哈特定律 |
当一个度量变成目标时，它就不再是好的度量 |
| Gilb's Law |
吉尔布定律 |
任何需要量化的东西，都能以某种方式度量，总比不度量好 |
Quality 质量
| 定律 |
中文名 |
核心含义 |
| Boy Scout Rule |
童子军规则 |
让代码比你发现时更好 |
| Murphy's Law |
墨菲定律 |
凡是可能出错的，就一定会出错 |
| Postel's Law (Robustness Principle) |
伯斯塔尔定律（鲁棒性原则） |
发送时保守，接收时宽容 |
| Broken Windows Theory |
破窗理论 |
不要留下"破窗"（坏设计、错误决策、差代码）不修复 |
| Technical Debt |
技术债务 |
技术债务是一切拖慢软件开发速度的东西 |
| Linus's Law |
林纳斯定律 |
眼睛足够多，所有 bug 都是浅显的 |
| Kernighan's Law |
柯尼汉定律 |
调试的难度是编写代码的两倍 |
| Testing Pyramid |
测试金字塔 |
大量快速单元测试 > 较少集成测试 > 少量 UI 测试 |
| Pesticide Paradox |
杀虫剂悖论 |
反复运行相同测试，效果会递减 |
| Lehman's Laws of Software Evolution |
雷曼软件演化定律 |
反映真实世界的软件必须演化，且演化有可预测的极限 |
| Sturgeon's Law |
斯特金定律 |
任何事物的 90% 都是垃圾 |
Scale 规模
| 定律 |
中文名 |
核心含义 |
| Amdahl's Law |
阿姆达尔定律 |
并行化加速受限于不可并行部分的比例 |
| Gustafson's Law |
古斯塔夫森定律 |
通过增大问题规模，可以在并行处理中获得显著加速 |
| Metcalfe's Law |
梅特卡夫定律 |
网络的价值与用户数的平方成正比 |
Decisions 决策
| 定律 |
中文名 |
核心含义 |
| Dunning-Kruger Effect |
达克效应 |
对某事了解越少，越容易自信 |
| Hanlon's Razor |
汉隆剃刀 |
能用愚蠢或粗心解释的，不要归因于恶意 |
| Occam's Razor |
奥卡姆剃刀 |
最简单的解释通常最准确 |
| Sunk Cost Fallacy |
沉没成本谬误 |
因已投入的时间/精力而坚持一个错误选择 |
| The Map Is Not the Territory |
地图非疆域 |
对现实的描述不等于现实本身 |
| Confirmation Bias |
确认偏误 |
倾向于偏好支持已有信念的信息 |
| Hype Cycle & Amara's Law |
技术成熟度曲线 & 阿马拉定律 |
短期高估技术影响，长期低估技术影响 |
| Lindy Effect |
林迪效应 |
存在越久的东西，越可能继续存在 |
| First Principles Thinking |
第一性原理 |
把复杂问题拆解到最基本的要素，再从头构建 |
| Inversion |
逆向思维 |
通过考虑相反结果并反向推导来解决问题 |
| Pareto Principle (80/20) |
帕累托法则 |
80% 的问题来自 20% 的原因 |
| Cunningham's Law |
坎宁安定律 |
在互联网上获得正确答案的最好方法是发布一个错误答案 |
评论