1. 帕金森定律：工作会膨胀以填满可用的时间。
2. 霍夫斯塔特定律：事情总是比你预期的要长，即使你已经考虑了霍夫斯塔特定律。
3. 布鲁克斯定律：向一个已经延期的软件项目增加人力只会让它更加延期。
4. 康威定律（及逆康威定律）：组织做的设计往往是其内部沟通结构的复制品。
5. 坎宁安定律：在互联网上获得正确答案的最佳方式不是提问，而是发布一个错误答案。
6. 斯特金定律：90%的东西都是垃圾。
7. 扎温斯基定律：每个程序都试图扩展，直到能够读取邮件。那些无法如此扩展的程序会被能够做到的程序所取代。
8. 海勒姆定律：当 API 的用户数量足够多时，你在合约中承诺什么并不重要：系统的所有可观察行为都会被某些人所依赖。
9. 普赖斯定律：在任何群体中，50%的工作是由其总人数的平方根数的人完成的。
10. 林格尔曼效应：群体中个体成员的生产力随着群体规模的增大而逐渐降低的趋势。
11. 古德哈特定律：当一项指标成为目标时，它就不再是一个好的指标。
12. 吉尔布定律：任何你需要量化的东西，都可以通过某种方式进行测量，这总比完全不测量要好。
13. 墨菲定律：可能出错的事就一定会出错。

1. 帕金森定律

工作会膨胀，直到填满可用的时间。

这是一个著名的定律，经常被用来为虚假的（有时是不合理的）截止日期辩护。

2. 霍夫斯塔特定律

即使你考虑到霍夫斯塔特定律，事情总是比预期花费更长时间。

软件项目几乎总是延迟，即使你已经考虑了缓冲时间。所以，如果你用帕金森定律来为短期限做辩解，你只能选择：

- 完全烧尽你的团队

- 永远延迟

3. 布鲁克斯定律

在一个已经延迟的软件项目中增加人力只会使项目更加延迟。

那句著名的话是：“九个女人也无法在一个月内生出一个孩子。”

每个承受压力的工程经理（EM）都知道这种感觉，当上级说：“这个项目超级紧急，你可以从其他团队调配任何需要的人。” 嗯…或者干脆别打扰我，让我们工作 🙃

4. 康威定律

组织会产生与其内部沟通结构相似的设计。

例如，一个SaaS公司有前端和后端团队。这些团队分开操作，他们的沟通结构影响了产品架构：

- 前端团队构建了一个用户界面，期望数据以某种格式呈现。

- 后端团队根据自己的假设构建API。

然而，API的响应与前端期望的格式不完全匹配，这就需要额外的转换。

随着时间的推移，这个SaaS应用最终会积累大量的胶水代码和低效之处，因为团队没有紧密合作。

5. 康宁汉姆定律

在互联网上获得正确答案的最好方法不是提问，而是发布错误的答案。

人们喜欢纠正他人：

6. 斯特金定律

90%的东西都是垃圾。

这类似于80/20的帕累托法则，只不过更极端。不管是代码、想法还是功能，大多数东西都很糟糕。

7. 扎温斯基定律

每个程序都会尝试扩展，直到它能够读取邮件。那些无法扩展的程序会被能够扩展的程序取代。

在AI时代，这一点尤其真实！现在在任何地方添加聊天机器人（或任何功能）变得如此简单，最终让你的产品变成了一个庞大的怪物。也许你的客户仍然在产品外部使用一些电子表格，这也没关系…

8. 海鲁姆定律

当一个API的用户足够多时，合同中你承诺的内容已经无关紧要：系统的所有可观察行为都会被某些人依赖。

这个定律真是太搞笑了：

9. 普莱斯定律

在任何群体中，50%的工作是由平方根数量的人完成的。

例如：

- 如果你有10名工程师，那么一半的产出可以归功于其中的3个人。

- 如果你有100名工程师，那么10个人的产出就相当于另外90个人的总和。

10. 林格曼效应

随着群体规模的增加，群体中的每个成员生产力往往会逐渐下降。

我震惊地发现，这一现象早在100多年前（1913年）就被发现并分析了，最初是在一次拉绳比赛中进行的。每个组参与的人越多，成员的努力就越少：

11. 古德哈特定律

当一个衡量标准变成目标时，它就不再是一个好的衡量标准。

这个定律非常有名。在科技领域，它常被提起，意思是你不应该衡量代码行数或拉取请求（PRs），因为人们（理所当然地）会通过这种方式来“作弊”。

12. 吉尔布定律

任何你需要量化的东西，都可以以某种方式进行衡量，而这种方式总比不衡量要好。

基本上就是说，虽然衡量可能很困难，而且测量结果可能并不完全准确，但任何测量总比没有测量要好。

13. 莫菲定律

任何可能出错的事情，最终都会出错。

没有莫菲定律的列表是不完整的 :)

原内容链接：

# The 13 software engineering laws：
https://newsletter.manager.dev/p/the-13-software-engineering-laws

翻译、漫画汉化：sagima