摘要：在软件开发这个充满变数的世界里，有些规律就像物理定律一样不可违背。无论你是刚入行的新手，还是带团队的技术管理者，这15条定律都会在某个时刻让你恍然大悟：你可真是个小可爱！

目录

一、帕金森定律 Parkinson’s law

二、侯世达定律 Hofstadter’s law

三、布鲁克斯定律 Brooks’ law

四、康威定律 Conway’s law

五、坎宁安定律 Cunningham's Law

六、斯特金定律 Sturgeon's Law

……

十四、德米特法则 Demeter's Law

十五、小黄鸭调试定律 Rubber Duck Debugging

十六、写在最后

在软件开发这个充满变数的世界里，有些规律就像物理定律一样不可违背。无论你是刚入行的新手，还是带团队的技术管理者，这15条定律都会在某个时刻让你恍然大悟：你可真是个小可爱！

有些定律你可能早就听说过，有些则相对小众，还有一些纯属程序员的自嘲。但它们对工程师和管理者来说都极其有用，15条都听过的我们一般称之为码神，看看你知道几个？

一、帕金森定律 Parkinson’s law

工作会膨胀到填满所有可用的时间。

这个定律实在是太过有名，以至于说出它的定义你会觉得：就这？我上我也能总结。

管理者设置 deadline，本质上是在玩“质量、成本、时间”的不可能三角。 一个明确的截止日期，往往能逼出更高的效率和更好的结果。当然这是理想情况，然而我们都清楚虚拟环境顺风顺水，生产环境一点就炸的客观规律，理想情况往往只存在于上线之前，一旦上线就会坍缩成Bug feature满天飞的状态。

二、侯世达定律 Hofstadter’s law

即使你已经考虑到了侯世达定律，事情总是会比你预期的时间更长。

这条定律与第一条的帕金森定律可谓是相得益彰。软件项目几乎总是会延期，即使你已经考虑了缓冲时间。所以如果你用帕金森定律来为紧张的 deadline 辩护，你要么会：

这两个定律涵盖了估算工期为什么如此困难的本质：

给无限的缓冲时间——你会把时间浪费在无意义的工作上。

缓冲时间太短——你会延期。

事已至此，延迟发版呗～

三、布鲁克斯定律 Brooks’ law

在已经延期的软件项目中增加人力，只会让项目更加延期。

每个被项目 deadline 压得喘不过气的架构师，都可能听过领导那句“关怀备至”的话：“这个项目非常紧急，其他团队的人你随便调！”

听到这话，你的内心 OS 可能是：大佬，您可闭嘴吧，让我们安安静静地干活行吗？

只要你是个技术管理者，就必然会经历项目延期，但很多管理者其实并未完全理解布鲁克斯定律的威力。

举个例子：一个4人团队的项目延期了，领导大发慈悲，给你派来了2位资深工程师。 你心里盘算着，就算带新人有成本，产出无法增加50%，但提升个5-10%总没问题吧？

然而，现实往往是残酷的：你的项目进度，反而更慢了！ 新人需要熟悉代码、老人需要分心指导、沟通成本指数级上升……这些都拖慢了整个团队的脚步。

四、康威定律 Conway’s law

组织设计出来的系统，其结构就是该组织沟通结构的复制品。

简单来说，你的团队怎么沟通，你的代码架构就会长成什么样。

比如，一个SaaS公司有独立的前端和后端团队。 由于团队是割裂的，他们的沟通结构直接影响了产品架构：

前端团队构建UI，期望数据是A格式。

后端团队基于自己的理解开发API，返回的是B格式。

结果，API数据和前端期望不匹配，中间就需要增加一堆转换代码。

久而久之，系统里充满了这些“胶水代码”，效率低下，只因团队协作不畅。

高手会反过来利用这条定律，变成了“逆康威定律”——你想要什么样的架构，就先把团队调整成那样的沟通结构。

五、坎宁安定律 Cunningham's Law

在网上获得正确答案的最佳方式，不是抛出一个问题，而是发布一个错误的答案。

这是一种高级的互联网钓鱼方式，帮助你成功打破次元壁，防止被卡在原地。

与其给协作团队提工单，眼巴巴地等他们排期、处理、上线，不如自己动手，直接给他们的项目提一个 PR，这个 PR 内容不重要，操作逻辑也不重要，重要的是让对方团队看到：

第一反应：兄弟你在玩什么抽象？

然后：PR评论，这里应该怎么改……

一来二去，下次你就知道怎么做了。

类似的case发生多次以后，对方团队也受不了，最后这个流程就标准化、自动化了。

完美。

六、斯特金定律 Sturgeon's Law

任何事物，百分之九十都是垃圾。

遗憾的是，无论是代码、点子还是产品功能，绝大部分都没什么用。

你发布的大部分功能，最终都会无人问津，沦为“僵尸功能”；而那一小部分，则构成了公司的核心产品。

我们常说的“10倍工程师”，不是指他写的代码量是别人的10倍，而是他创造的有效价值是别人的10倍。

如果我们只是个没有感情的“工具人”，产品经理给什么需求我们就做什么，那我们很可能就是在用90%的时间，去制造那90%的垃圾。

七、扎温斯基定律 Zawinski’s Law

每个程序都会试图扩展到能够读取邮件的程度。那些不能如此扩展的程序会被能够扩展的程序所取代。

在如今这个AI时代，这条定律简直不能更贴切了！现在可能要改成：

“每个程序都会不断膨胀，直到它能接入一个大语言模型。” 往任何产品里塞一个聊天机器人（或任何新潮功能）都变得如此容易，最终让你的产品变成一个臃肿不堪的“四不像”。

这就是“功能蔓延”(feature creep) 的根源——无休止地添加新功能，直到它们开始侵蚀产品的核心价值。

用户会抱怨产品越来越复杂、越来越难用，找不到自己真正需要的功能。 尤其是新用户，打开一看，直接被劝退。

八、海勒姆定律 Hyrum’s Law

当你的API拥有足够多的用户时，你在文档里承诺什么根本不重要了：你系统中所有可被观察到的行为，都必然会被某些用户所依赖。

通俗点说就是：只要用户够多，任何 Bug 都会被当成 Feature 来用。

这条定律不仅适用于API，也适用于产品功能。

正如“斯特金定律”所说，90%的功能都是“垃圾”。 但是，你却要花费100%的精力去维护它们。因为只要你发布一个功能，哪怕再烂，也总会有那么一两个“奇葩”用户在用。

当你试图下线这个功能时，他们就会跳出来哭天喊地，然后某些业务方的同学就会来施压，让你继续支持。很多技术债和“屎山”就是这么来的。

这也是为什么“功能开关” (Feature flags) 容易被滥用：它给了产品经理一个不做艰难决策的借口——不下线功能，而是把它藏在开关后面，结果代码越来越复杂。

此时一位张姓产品经理有话要说：每天有几亿人要教我做产品……

九、普莱斯定律 Price's Law

在任何一个团体中，50%的工作是由占总人数平方根的成员完成的。

举个例子：

一个10人的工程师团队，其中大约3个人（√10 ≈ 3.16）完成了团队一半的工作。

一个100人的工程师团队，其中10个人（√100 = 10）的产出，就相当于另外90人的总和。

这条定律，很可能是当代互联网世界降本增笑的核心依据之一。

十、林格曼效应 The Ringelmann effect

团队规模越大，个体成员就越倾向于变得不那么高效，即“人浮于事”。

这个现象早在100多年前（1913年）就在一场拔河比赛中被发现了。 实验发现，参与拔河的人越多，每个人出的力就越少。

林格曼总结了两个原因：

这个效应在脑力劳动中同样适用。 很多大厂的“内卷”和低效，根源就在于此。

十一、古德哈特定律 Goodhart's Law

当一个指标变成了目标，它就不再是一个好的指标。

这条定律在科技圈广为人知，经常被用来反驳那些用“代码行数”或“PR数量”来衡量工程师绩效的做法，因为这些指标太容易被“刷”了。

任何KPI都可能被“玩坏”：

目标：收入？ → 疯狂打折，亏本赚吆喝。

目标：用户流失率？ → 把取消订阅的按钮藏到用户找不到的地方。

目标：新用户数？ → 狂砸广告，引来一堆“垃圾”流量。

目标：工单解决时长？ → 快速关闭工单但根本不解决问题（作为客户你肯定体验过）。

敏捷开发里的“速度分”、燃尽图等指标也一样，任何单一的度量都可能很快失效。

但是，答案并不是“我们不应该度量”。 如果因噎废食，我们就会掉进下一个定律的陷阱。

十二、吉尔布定律 Gilb's Law

任何你需要量化的东西都可以用某种方式测量，这比完全不测量要好。

简单说就是：

测量可能很难，结果可能不准，但任何测量都好过两眼一抹黑凭感觉。

这是对“古德哈特定理”的完美平衡。我们不应该因为怕被“刷数据”就放弃度量，而是应该从一个不完美的度量开始，然后持续改进它。

在开发者生产力领域，我们已经看到了这种演进：从DORA、SpaceX到DevEx，各种度量框架层出不穷，各有千秋。

十三、墨菲定律 Murphy's Law

任何可能出错的事情，就一定会出错。

我们都喜欢拿它开玩笑，但你肯定经历过类似场景：

项目火烧眉毛，你急着上线一个功能。有一个边界条件，测试起来特别复杂，你心存侥幸：“这种情况不可能发生吧？” 于是你决定抄个近道，不处理了。

你猜下个周末半夜，在生产环境搞出大新闻的是什么？

不要心存侥幸，莫伸手，伸手必被抓。

十四、德米特法则 Demeter's Law

一个对象应该对其他对象有尽可能少的了解。

也被称为“最少知识原则”或“只跟朋友说话”。简单来说，就是一个模块不应该知道它所操作对象的内部细节。

这个定律不仅适用于代码架构，也适用于团队管理。在代码层面，它能降低耦合度，让系统更容易维护。在团队层面，它意味着：

不要让前端工程师直接操心数据库优化问题。

不要让后端工程师去纠结UI细节。

每个团队专注于自己的领域，通过清晰的接口协作。

违反这个原则的典型场景是：产品经理直接找开发要数据库访问权限来查数据，结果把生产环境搞崩了。记住，专业的事情交给专业的人做。

十五、小黄鸭调试定律 Rubber Duck Debugging

向小黄鸭解释你的代码，通常能找到bug所在。

这可能是程序员世界里最可爱的定律了。当你卡在一个bug上时，试着向一只橡皮鸭（或任何无生命物体）详细解释你的代码逻辑。神奇的是，在解释的过程中，你往往会突然发现问题所在。

这个定律背后的科学原理是：当你被迫用自然语言描述代码逻辑时，你的大脑会从不同角度重新审视问题。这种"费曼学习法"不仅适用于调试，也适用于：

代码评审：让别人理解你的代码。

技术分享：能讲清楚说明你真的懂了。

面试：面试官问“请解释一下这段代码”时。

现在很多程序员都在桌上放一只小黄鸭，这已经成为程序员文化的一部分。有些公司甚至在会议室里准备了专门的"调试鸭"。

当然，在这个AI时代，你也可以跟大模型解释你的问题——不过记住，有时候橡皮鸭比AI更靠谱，因为它不会给你错误的建议

十六、写在最后

在这个AI大模型满天飞、35岁程序员焦虑症高发的时代，掌握这些定律比掌握最新的技术栈可能更重要。毕竟，技术会过时，但人性和组织的复杂性是永恒的。

无论你是在大厂996，还是在外企朝九晚五，这些定律都会在某个深夜debug时、某次项目延期时、某个需求变更时，让你会心一笑：“原来如此，又中招了。”

从严肃的布鲁克斯定律到可爱的橡皮鸭调试定律，这15条定律涵盖了软件工程的方方面面。有些让你避坑，有些让你思考，还有些纯粹让你开心一下。

记住，软件工程不只是写代码，更是理解人、理解组织、理解这个复杂世界的游戏规则。愿你在这个行业里，既能写出优雅的代码，也能过上优雅的人生。

P. S. 如果你的橡皮鸭突然开始跟你说话，那可能不是因为调试定律，而是因为你该休息了。

来源：dbaplus社群