【规律之手】资深码农都懂？软件工程中的13条“潜规则”定律

请点击上方蓝字TonyBai订阅公众号！

大家好，我是Tony Bai。

做软件开发时间越长，越觉得背后似乎有只“无形的手”在影响着项目进度、团队协作甚至技术决策。有些现象反复出现，让人不得不感慨其中蕴含的“规律”。

最近看到国外一位开发者总结了软件工程领域的13 条“定律” (Laws)。它们虽然不像物理定律那样严格，但确实精准地捕捉到了我们日常工作中经常遇到的挑战和现象，堪称是宝贵的“经验法则”或“心智模型”。

分享给大家，看看你对哪些深有体会：

1. 帕金森定律 (Parkinson's law): 工作会填满所有可用时间。 (任务总能拖到死线前完成?)

2. 霍夫施塔特定律 (Hofstadter's law): 事情总是比预期的要长，即使考虑了这一定律。 (估时永远不准？)

3. 布鲁克斯定律 (Brooks' law): 给延期的项目加人会让项目更延期。 (人月神话?)

4. 康威定律 (Conway's law): 组织沟通方式决定系统设计。 (你的架构是不是反映了你的团队结构?) (+ 逆康威定律)

5. 坎宁安定律 (Cunningham's law): 获取正确答案的最佳方式是发布一个错误答案。 (想得到反馈？先大胆“错”一个？)

6. 斯特金定律 (Sturgeon's law): 任何事物 90% 都是垃圾。 (你做的功能多少是真正有价值的？)

7. 扎文斯基定律 (Zawinski's law): 程序总想扩展到能收发邮件。 (警惕功能蔓延!)

8. 海勒姆定律 (Hyrum's law): API 的所有可观察行为都会被依赖，无论你承诺什么。 (接口行为不能轻易改动!)

9. 普莱斯定律 (Price's law): 50% 的工作由平方根数量的人完成。 (团队里的核心贡献者？)

10. 瑞格曼效应 (The Ringelmann effect): 团队越大，个体效率越低。 (人多不一定力量大？)

11. 古德哈特定律 (Goodhart's law): 度量一旦成为目标，就不再是个好度量。 (警惕 KPI 陷阱!)

12. 吉尔布定律 (Gilb's law): 任何需要量化的东西都可被某种方式量化（总比不量化好）。 (与上一条辩证看，还是要量化!)

13. 墨菲定律 (Murphy's law): 会出错的事总会出错。 (那个被你忽略的边缘 Case...？)

理解这些“定律”，能帮我们更好地认识软件开发中的复杂性，识别潜在风险，做出更明智的决策，少踩一些坑。

大家对这些定律怎么看？哪些是你深有体会的？或者你还知道其他有趣的“软件工程定律”吗？

欢迎在评论区分享你的看法和经历！

(原始文章对每条定律有更详细的解释和漫画，感兴趣的同学可以搜索"The 13 software engineering laws^[1]"进一步阅读)

本公众号的世界读书日赠书活动火热进行中，欢迎各位小伙伴点击链接，积极参与，赢取本人亲笔签名的赠书😁。

参考资料

[1] 

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

如果本文对你有所帮助，请帮忙点赞、推荐和转发！