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