一个名为《Laws of Software Engineering》的独立网站，把 56 条常见软件工程“定律”做成了卡片式索引。可以搜索，可以分类浏览，还提供 JSON API，并延伸出书和海报。

这事不算什么行业大新闻。它既不是学术新发现，也不是哪家公司的工程规范发布。它更像一次整理：把散落在书、博客、演讲和工程圈黑话里的经验法则，打包成一个更顺手的入口。

值得看，但别看错。真正要判断的，不是这些 law 有没有名气，而是软件行业为什么总爱把复杂经验压成一句话；以及一句话一旦变成卡片、海报和 API，帮你的是记忆，坑你的往往是语境。

这网站到底收了什么，对谁有用

站点目前收录 56 条 laws，按 Architecture、Teams、Planning、Quality、Scale、Design、Decisions 等维度分类。每条都用卡片展示，方便检索和跳转。形式很轻，指向很明确：让你快速找到一句常被引用的工程原则。

覆盖面不小，至少能看出它不是只收分布式系统黑话，也不是只做管理学语录。代表性的几条，大致如下：

Law常见含义典型使用场景
Conway's Law组织沟通结构会映射到系统结构架构拆分、团队边界设计
Brooks's Law延期项目继续加人，常常会更晚项目救火、排期失控
Hyrum's LawAPI 一切可观察行为都会被用户依赖平台接口、兼容性治理
Gall's Law可运行的复杂系统通常从可运行的简单系统演化而来系统演进、从零搭建
Goodhart's Law指标一旦成目标，就不再是好指标OKR、绩效、质量度量
CAP Theorem分布式系统里一致性、可用性、分区容错不能同时极致满足存储、服务治理、架构取舍

除此之外，像 YAGNI、DRY、KISS 这类开发者熟到不能再熟的原则，也在这类整理里经常一起出现。可见它收的不是严格同质的一类东西。有的是理论，有的是经验总结，有的是启发式，有的甚至更接近工程圈约定俗成的提醒语。

所以别把它看成“自然科学定律大全”。更准确的说法，是软件工程常识的索引页。

对谁有用？主要是三类人：

  • 有一定开发经验的工程师.拿它补记忆，查术语，快速回忆某条原则原本在讲什么。
  • 架构师.拿它做讨论入口，给方案评审找共同语言。
  • 技术管理者.拿它做培训材料、内部分享提纲，或者帮助团队建立最低限度的共识。

如果你正准备写团队手册、做架构评审、整理培训资料，这种网站确实省时间。至少比在搜索引擎里捞一堆零散博客要整齐得多。

但它的价值也大体止步于此：整理得更顺手，不等于判断得更正确。

软件工程为什么这么爱造“定律”

因为复杂性太贵。

软件工程里最难的，常常不是写代码，而是用有限时间做不完美判断。要不要拆服务，能不能晚点优化，要不要加人救火，指标该怎么设，接口该不该兼容旧行为。这些问题没有标准答案，但团队又必须尽快拍板。

于是“定律”就成了会议里的快捷键。报一句 Conway、Brooks、Goodhart、CAP，讨论立刻省掉半截。它们的作用，本来是压缩经验。问题在于，压缩这件事很容易顺手把限制条件也删了。

这才是我不太买账的地方。很多团队不是在用 law 帮助思考，而是在用 law 结束思考。

拿几个常见场景说得更直白一点：

  • 用 Conway's Law 给糟糕组织结构开脱，好像系统耦合不是设计问题，而是宿命。
  • 用 YAGNI 否掉一切中期准备，把“别过度设计”偷换成“别提前负责”。
  • 用 Brooks's Law 反对任何补人动作，却不去拆任务边界、交接成本和沟通链路。
  • 用 CAP 当挡箭牌，仿佛说出三个字母，就已经完成了架构决策。

这些话本身未必错。错的是拿它们当免思考通行证。

“天下熙熙，皆为利来。”这句话放到软件工程语境里也成立。金句之所以流行，不只是因为它们对，还因为它们便宜。传播便宜。复述便宜。装懂也便宜。真要把业务约束、系统负债、迁移成本、团队能力讲清楚，太慢，也太容易暴露判断者其实没想明白。

所以，软件工程热爱“定律”，背后不是神秘文化，而是组织激励：一句短话最适合会议、文档、培训、海报，也最适合被 API 化、模板化、搜索化。

这不是原则的错。原则本来就是路标。问题出在很多人把路标抢来当方向盘。

这对工程师、架构师和技术管理者分别意味着什么

对工程师，这类网站最适合当索引，不适合当答案。

你可以拿它快速复习概念。比如评审前回看 Hyrum's Law，提醒自己任何可观察行为都可能形成依赖；或者在重构前想到 Gall's Law，先做能跑的小版本，再谈复杂演进。这个用法很实在。

但动作也要跟上。看完卡片，下一步应该是补上下文：这条 law 适用的前提是什么，在你的系统里约束是什么，代价由谁承担。如果只会引用，不会落地，知道得越多，越像会说黑话的复读机。

对架构师，风险更高。

你最容易把这些 law 变成“论证捷径”。评审会上甩一句 KISS、DRY、不要 premature optimization，听起来都像正解。可很多时候，真正该展开的是模块耦合、团队交付节奏、运维负担、兼容成本。那些硬账不算，原则就会沦为话术。

更具体一点，如果你负责架构评审，这类站点可以这样用：

  • 会前用来统一术语，避免团队各说各话。
  • 会中只把它当提醒，不把它当结论。
  • 会后把每条被引用的原则，翻译成可验证的设计约束和取舍记录。

对技术管理者，这东西很顺手，也最容易被滥用成“贴墙管理”。

做培训、写团队手册、给新人补课，它都很好用。书、海报、卡片式展示，天然适合内部传播。问题是管理层一旦沉迷这种压缩表达，就会把复杂治理误做成口号治理。

历史上这种事见得太多。管理学、敏捷、设计模式，都走过类似的路：先是经验总结，后来变成培训材料，再后来变成组织表演。不完全一样，但味道很像。今天 software engineering laws 被做成网站、海报和 API，至少说明一件事：行业在沉淀记忆，也在加速把判断外包给格式化表达。

接下来真正值得观察的，不是它会不会再多收几条 law，而是这些整理会不会继续嵌进团队工具链。

几个现实变量比“网站火不火”更重要：

接下来该看什么为什么重要
团队会不会把这类 law 列表写进培训和评审模板一旦进入模板，引用会从自发变成半强制
API 会不会被检索工具或代码助手拿去调用一旦进入工具，原则会更频繁地变成默认建议
使用者会不会补充适用边界和反例没有边界，原则就容易变成口号
站点后续是继续扩充索引，还是形成更强的“标准答案”口吻前者是资料库，后者更像认知预制菜

我更在意第二条。如果这类内容只是海报，问题还有限；如果它开始进入 AI 检索、开发助手、团队工作流，影响就会放大。到那时，被外包的就不只是记忆，而是判断习惯。

软件工程当然需要原则。没有原则，团队只会在重复踩坑里打转。但原则一旦脱离情境，就会从经验沉淀变成责任转移。地图不是疆域，这句话拿来反过来看这份 law 清单，正合适。