每个程序员必知的13条魔鬼定律：90%代码终将沦为垃圾
神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。
编者按：13条浓缩行业智慧的工程定律，既有帕金森、墨菲等经典法则，更暗藏康威定律逆用等实战密码，助工程师破局低效陷阱，管理者驾驭复杂项目。文章来自编译。
有的广为人知，有的则较为生僻。但所有这些定律对工程师和管理者都极其有用。
看看有多少条是你第一次听说的：
帕金森定律
侯世达定律
布鲁克斯定律
康威定律（及逆康威定律）
坎宁安定律
斯特金定律
扎温斯基定律
海勒姆定律
普莱斯定律
林格尔曼效应
古德哈特定律
吉尔布定律
墨菲定律
针对每条定律，我会分享：
定律定义
相关漫画（如果找得到的话）
对工程管理者的重要性
开始吧。
1、帕金森定律（Parkinson’s law）
工作就是这样，给多长时间就拖多久。
这条著名定律常被用来为虚假（或不合逻辑）的截止日期辩护。
最好拖到最后一刻交作业，这样能证明你有多努力，工期有多不合理
重要性
在James Stanier的客座文章中，我们曾深入探讨过这一点：设定截止日期通常能提升效率，关键在于平衡范围、资源和时间的"铁三角"。
跟所有定律一样，这条也可能会被滥用——这时候就要拿出侯世达定律来制衡：
2、侯世达定律（Hofstadter’s Law）
项目的耗时永远会超出预期，哪怕你已经考虑到这条定律本身。
软件项目几乎总会延期，即便已经预留出缓冲时间。所以如果想用帕金森定律设把截止日期设得短一点的话，会导致：
团队累趴
永远延期
怎么估算时间？先估个合理的数，然后翻倍，翻倍，再翻倍......
重要性
这两条定律揭示了软件估算为什么难的核心：缓冲过长会浪费资源，缓冲过短必然延期。
没有捷径——唯有靠大量实践、充分沟通（以及保持需求的可协商性）。
3、布鲁克斯定律（Brooks’ law）
给延误的软件项目增加人手只会耽搁更久。
经典类比："就算有9个女人也没法在一个月内生出孩子。"
增加2个人手对项目的作用......
重要性
所有工程管理者都经历过项目延期（参考前两条定律）。
多数管理者误以为增加2名资深工程师就能让项目提速5-10%，但现实可能更接近林格尔曼效应（稍后讨论）。
残酷真相是：效率可能变得更低！
4、康威定律（Conway’s law）
系统设计会复刻组织的沟通结构。
比方说，如果某SaaS公司的前端与后端团队是独立运营的话，其沟通模式会直接影响产品的架构：
前端团队按预期数据格式开发UI；
后端团队基于自身假设开发API；
因为API响应与前端预期不匹配，需提供额外的转换层；
长期缺乏协作导致系统堆积冗余的胶水代码，设计低效。
管理驱动组织架构设计，进而决定了软件架构
重要性
可用逆康威定律来优化流程：
Flo公司将移动端发布周期从3周缩短至每日20-30次——其做法是每支团队均配置1名iOS工程师、1名Android工程师+2-4名后端工程师，将核心功能移至后端实现高频迭代。
5、坎宁安定律（Cunningham’s law）
在互联网获取正确答案的最佳方式不是提问，而是发布错误答案。
人都喜欢纠正别人：
纠正别人比老婆喊上床重要
重要性
与其提交工单等待DevOps排期，不如直接提交漏洞百出的PR（Pull-Request）——即使毫无经验，也可参考已合并的PR，找个类似的，然后尽力而为。
这么做有几种效果：
DevOps团队马上会吐槽："这写的什么鬼？"
快速指出PR的修正项
你得到了实操经验
倒逼DevOps团队通过自动化与规范优化流程
6、斯特金定律（Sturgeon’s Law）
90%的东西都是垃圾。
这条好比加强版的帕累托法则——无论是代码、创意还是功能，大部分都是糟粕。
值得做的就那么10%
重要性
大多数功能终将无用，真正驱动业务的核心功能仅占10%。所谓10倍工程师，并不是指代码量十倍于人，而是价值创造10倍于人。
如果盲目实现产品经理的需求文档，很可能90%精力都耗费在无效功能上。
7、扎温斯基定律（Zawinski’s Law）
所有程序都会膨胀到能处理邮件为止，否则就会被其他程序取代。
AI时代尤其是这样！随意添加聊天机器人等功能会让产品臃肿不堪——也许用户继续用外部电子表格反而是好事。
所有软件都会不断增加功能，直到繁琐无比。然后就会被一个更“简单”的解决方案取代，后者再重蹈覆辙
重要性
这就是功能蔓延的根源——持续堆砌功能直至产品价值被稀释。用户抱怨产品复杂难用，新用户尤其无所适从！
8. 海勒姆定律（Hyrum’s Law）
当API用户足够多时，不管合同是怎么承诺的，系统的所有可观察行为都会被至少一个用户依赖。
真实案例令人啼笑皆非：
重要性
虽然定律针对API，但对功能也适用——如斯特金定律所述，90%的功能是垃圾。
但你还是得需维护所有的功能——一旦发布，必有用户使用。当你想移除某功能时，用户就会投诉，业务方也会施压保留。
我之前讨论过这个问题：功能开关本是利器，但可能被滥用为产品经理逃避功能删减决策的借口。
9. 普莱斯定律（Price's law）
在任何团队中，50%的产出由总人数的平方根个人贡献。
比方说：
10名工程师中的3个人就贡献了其中50%的产出；
100名工程师，其中的10人的贡献就相当于其他90人的产出。
我是看了Itzy Sabo在领英发的一篇文章知道这条定律的，他以此来解释Twitter裁员后为什么并没有崩溃：
2022年11月，马斯克裁掉Twitter 50% 的员工；
普莱斯平方根定律表明：继续裁员30%后，8000开平方≈90人即可维持核心产出。
重要性
团队扩张困难——如果想产出翻倍，你得招聘4倍的人力。这个现象可用林格尔曼效应解释：
10. 林格尔曼效应（Ringelmann effect）
团队规模越大，成员个人效率越低。
该现象早在1913年就被发现了：拔河实验表明，团队人数越多，个体出力越少。
人多个人就会偷懒
林格尔曼归因为这两点：
失去动力（社会惰化）；
协调成本。
重要性
PostHog公司开始实践小团队魔法（47人拆分为15个团队）；
初创企业尤需拆分小团队并明确责任边界。
11. 古德哈特定律
指标一旦成为目标，便失去衡量价值。
这条定律常被引用：切勿用代码行数或PR数量作指标，因员工会针对数据来优化行为。
重要性
所有KPI均可被操纵：
收入？→ 大打折扣；
流失率？→ 设置取消壁垒；
新增用户？→ 低质量广告引流；
工单解决时长？→ 快速关单而非解决问题。
12. 吉尔布定律（Gilb’s law）
任何需量化的事物，总会有测量的方法，比完全不测好。
那怕衡量方式不完美，也好过一点数据都没有。
重要性
这条定律是用来制衡古德哈特定律的——与其放弃衡量，不如逐步优化指标。
开发者效能领域已实践此理：DORA指标、SpaceX方法、开发者体验框架各有优势。
13. 墨菲定律（Murphy’s Law）
可能会出错的就一定会出错。
这份定律清单怎能少了墨菲定律呢？
重要性
赶工上线时，某个复杂边界案例看似无需测试，你决定忽略不管。
结果呢？猜猜看第二个周日的生产环境就被谁搞崩了？
亲身经历过4-5次后，我现在会强制验证所有的"小概率"事件。
结语
这些虽然不是"真正的定律"，但却是极佳的思维模型。愿它们能帮助你在日常工作中少踩一点坑。
译者：boxi。
