hacker-laws：程序员绕不开的那些定律和原则

写代码写久了，总会碰到一些解释不清的现象：为什么加人反而更慢？为什么需求永远估不准工期？为什么优化了 A 端，B 端又出问题？

这些问题，前人早就总结过了。

GitHub 上有个叫 hacker-laws 的仓库，专门收集开发者和工程师该知道的定律、理论、原则和模式，Star 数超过 27k。它不是教你写代码的教程，而是一本给技术人员看的"社会常识手册"。

Brooks’ Law：加人不一定加速

Fred Brooks 在《人月神话》里提出过一个观点：向一个已经延期的软件项目增加人手，只会让它更延期。新人需要时间熟悉代码和流程，沟通成本也会随着人数增加而上升。有些任务本身不可拆分，加再多的人也没用。“九个女人不能在一个月内生出一个孩子”，说的就是这个道理。

Hofstadter’s Law：工期永远估不准

Douglas Hofstadter 说过一句话：“事情总是比你预想的要久，即使你已经把霍夫斯塔特定律考虑在内了。” 这句话听起来像绕口令，但在软件开发里几乎是铁律。每次排期，大家心里都清楚：实际完成时间一定会超出预期。

Goodhart’s Law：指标一旦变成目标，就不再是好指标

当一个度量标准被当作考核目标时，人们会倾向于刷指标而不是做正确的事。比如代码覆盖率被当作 KPI，开发者可能会写出大量没有断言的测试来凑数。代码行数被用来衡量产出，代码库就会变得臃肿。这个定律提醒管理者：选错指标比没有指标更危险。

Gall’s Law：复杂系统从简单系统演化而来

John Gall 提出：一个能正常工作的复杂系统，一定是从一个能正常工作的简单系统演化而来的。从零开始设计的复杂系统从来都跑不起来，也没法修补。万维网就是一个典型例子，最初只是学术机构之间共享文档的简单协议，后来才逐步演变成今天这样庞大的系统。

CAP 定理：分布式系统的三选二

Eric Brewer 提出的 CAP 定理指出，分布式数据存储最多只能同时满足三个保证中的两个：一致性、可用性、分区容错性。网络分区不可能完全避免，所以在分区发生时，要么牺牲一致性保可用性，要么牺牲可用性保一致性。大多数现代数据库都把这个权衡交给了用户自己选择。

Conway’s Law：组织结构决定系统架构

这个定律说，系统的技术边界会反映组织的结构。如果一个公司由多个互相独立的小团队组成，那它做出来的软件也会是割裂的。反过来，如果团队围绕服务和功能来组织，软件架构也会跟着变。

Dunning-Kruger Effect：能力越差越自信

这个心理学效应在技术领域很常见：对一个领域了解越少的人，越容易低估解决问题的难度。随着经验增长，又可能走向另一个极端，低估自己的能力、高估别人的水平。意识到这些认知偏差的存在，本身就是克服它们的第一步。

Murphy’s Law：会出错的事总会出错

这条定律在开发者中间流传很广。测试环境跑得好好的，上了生产就出问题。本地复现不了的 bug，偏偏在客户那里稳定触发。虽然带有玩笑性质，但它提醒工程师要做好防御性设计。

结语

hacker-laws 仓库涵盖了几十条这样的定律和原则，从 Amdahl’s Law 到 YAGNI，从 Unix 哲学到 SOLID 原则，每一条都有清晰的解释和现实案例。它不长，适合随手翻阅。对于写了几年代码的人来说，很多内容会让人产生"原来这个现象早就有名字了"的感觉。

不需要把这些定律背下来，但知道它们的存在，下次遇到类似的情况时，至少能想到：这不是我一个人的问题，前人早就踩过这个坑了。

，但知道它们的存在，下次遇到类似的情况时，至少能想到：这不是我一个人的问题，前人早就踩过这个坑了。