文章目录hacker-laws程序员绕不开的那些定律和原则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 原则每一条都有清晰的解释和现实案例。它不长适合随手翻阅。对于写了几年代码的人来说很多内容会让人产生原来这个现象早就有名字了的感觉。不需要把这些定律背下来但知道它们的存在下次遇到类似的情况时至少能想到这不是我一个人的问题前人早就踩过这个坑了。但知道它们的存在下次遇到类似的情况时至少能想到这不是我一个人的问题前人早就踩过这个坑了。