在软件工程的世界里，总有某些规律如同地心引力般不可抗拒——它们让项目延期成为常态，让“屎山”代码野蛮生长，让团队在扩张中陷入内耗。

这些定律并非玄学，而是无数工程师用血泪验证的工程暗黑法则。今天，我们聚焦5条最具破坏力也最具启示性的定律，用真实案例揭开它们的狰狞面目与破解之道。

01

帕金森定律：

为什么你的项目永远在延期

？

“明明一周就能完成的计划，一定要拖到周五下班前”“部门工作人员越多，事情就越做不到”“领导画的蛋糕越大，越不敢直说”...

其实，这些不是什么“职场诅咒”，而是“帕金森定律”。

在1958年出版的《帕金森定律》中，诺斯科特·帕金森提出：“工作将填补分配给它的时间，员工将扩大到适应组织的规模”。

帕金森认为，工作会自动占满一个人所有可用的时间，工作总会拖到最后一刻才能完成。如果一个人给自己安排了充裕的时间去完成一项工作，他就会放慢节奏或者增加其他项目以便用掉所有的时间。工作膨胀出来的复杂性会使工作显得很重要，在这种时间弹性很大的环境中，人并不会感到轻松。相反会因为工作的拖沓、膨胀而苦闷、劳累，从而精疲力竭。

帕金森定律”告诉我们：人做一件事情，耗费的时间越长，就会感觉越累。工作会自动占满自己的时间，如果你给了自己充足的时间去完成某项工作，你一定会不自觉地放慢节奏至最后的时间期限，才集中精力去完成这项工作。所以，你会因为时间的拖沓和最后的紧迫感而感到劳累，筋疲力尽。

不过别担心，制订计划是应对“帕金森定律”的最有效手段。

你可以采用敏捷冲刺：拆解任务为1-2周小周期，制造健康紧迫感；或是倒排期限：用“如果只剩3天，必须砍掉什么？”倒逼优先级。

有了计划，才有了保障项目目标和方向的基本手段。

02

布鲁克斯定律：

延期项目加人？小心加速死亡

？

布鲁克斯法则是IBM 360系统之父弗雷德里克·布鲁克斯提出的经典理论，简单来说就是：项目已经延期时，加人不仅救不了火，反而可能火上浇油。

比如你和朋友做小组作业，原本3人分工明确，老师硬塞了3个新人，结果大家开会分任务、教新人就花了大半天，最后作业反而交得更晚。

布鲁克斯法则的核心问题在于流程臃肿导致效率崩盘，而解决方法不是加人，而是优化流程设计。

至于如何破局，小渡给出几点建议：

• 不要用人力去解决问题，而要缩小范围；

• 延迟功能，而不是你的理智；

• 让小型、专注的团队拥有垂直切片而不是整个披萨；

因为代码不会因为键盘上手指的增多而神奇地变得更快，它只会在更多地方出错。

布鲁克斯法则的本质是提醒我们：效率来自科学的设计，而非人力的堆砌。通过小团队、快迭代、需求聚焦和工具辅助优化流程设计，才能避免“人越多、活越乱”的陷阱。

03

斯特金定律：

90%的代码都是垃圾，你为何还在埋头生产？

？

下面是来自程序员的每日暴击：

为兼容某个边缘业务写的特殊逻辑，三年无人调用；

过度设计的抽象层，让简单需求改造成本飙升；

产品经理坚持开发的“年度重磅功能”，上线后使用率0.3%...

一个反常识真相是：“垃圾”并非指BUG，而是低价值、高维护成本的存在。它们消耗工程师最宝贵的资源——注意力。

小渡给到你的行动指南则是： 

用数据杀人：监控功能使用率（如通过埋点统计），用证据砍掉僵尸代码；

追求10倍工程师思维：不是写10倍代码，而是用1/10代码解决核心问题（如Notion用极简架构实现复杂功能）；

用户价值优先级：每次写代码前灵魂拷问——“这属于那10%的黄金部分吗？”

 

04

墨菲定律：

那个不可能发生的bug，为何总在凌晨爆发？

？

墨菲定律是最著名、最广为人知的定律，它通常被表述为：“凡事只要可能出错，那就一定会出错。”

不过，真要说触及所有工程师痛处的还要数墨菲第二定律：“任何解决方案都有自己的问题”，或者，没有什么事情像看起来那么简单。

墨菲第二定律雄辩地总结出了以下观察结果：作为工程师，我们接触的任何东西都会增加系统的风险，因此，可以通过避免系统更改来降低风险。

关于墨菲定律，小渡有以下建议：

首选流程变革和供应商软件，而不是自主开发的解决方案；

避免陷入快速解决方案陷阱，因为你以后不得不回过头来改进。第一次就把它做好；

测试。测试。测试。测试覆盖率越高，应用程序就越能适应复杂的环境。

05

斯康威定律：

为什么你的架构图就是公司组织架构的翻版？

？

康威定律是由计算机科学家 Melvin Conway 提出的。是一条关于组织设计和系统架构的经验法则。

康威定律的内容可以简单地概括为：“组织设计产生系统设计的影响”，通俗地说就是：“系统的结构受到设计它的组织结构的影响”。

这条定律的具体表述是：“在一个组织中，任何一个设计出来的系统，其结构都会与该组织的沟通结构保持一致。”

换句话说，如果一个组织的结构是分为多个小组分别独立开发某个系统的各个模块，那么最终这个系统的结构也会被划分为许多模块，并呈现出分布式的特点。

下面这几种方法，可以有效帮你在工作中摆脱康威定律。

1.最重要的工作应该在时区重叠的时间内完成。

2.在招聘和组织工作中考虑到这种限制因素。虽然这很可能是你无法控制的，但你可以尝试向你的经理们传达康威定律。

3.接受它。如果你所在的组织是分布式的，那么或许你们的系统也应该是分布式的。避免与组织结构不协调的系统架构。

以上5个定律，是软件工程中比较常见的定律和决策原则。

作为软件工程师，了解和掌握这些基本的定律和原则，可以帮助我们更好的解决软件开发中的哪些复杂的问题，做出高质量的设计和决策，能够采取适当的措施，以交付优秀的产品。

同时，这些基础的定律和原则，可以作为软件团队开展工作的指导性原则，以帮助团队找到适合自身实际情况的最佳实践和策略。

正如《人月神话》作者Brooks所言：“没有银弹，但有更好的猎枪。” 理解黑暗法则，正是为了在工程的黑暗森林中，点燃那一簇不灭的理性之火。

阅读原文：原文链接