读《程序员修炼之道》札记

初读《程序员修炼之道》是在入行第二年，当时只觉得是一本格言集。多年后重读，才发现当年划线的句子，如今每一句都能对应到一次具体的项目事故。

正交性

书中把「正交性」定义为：一个组件的改变不影响其他组件。这个概念今天换了个名字叫「解耦」，但精髓常常在落地时丢失。

正交性不是架构图上的虚线框，而是修改成本的可测量属性：改一个地方，有多少地方跟着坏？

我见过最讽刺的反例：一个「微服务」架构里，改一行状态码枚举要同时发五个仓库的 PR。服务拆得越多，正交性可能越差——正交性是关于依赖方向的，不是关于服务数量的。

曳光弹与过早优化

「曳光弹」一章讲的是：先打一发会发光的子弹确认弹道，而不是先计算整个弹道模型。翻译成工程语言就是——用最小实现验证端到端路径，再逐步夯实。

这和「先让它跑起来，再让它跑得快」的朴素常识是一致的，但书中给出了一个更精确的版本：优化要基于测量，测量要基于一个已经工作的系统。没有工作系统的优化，优化的是一个假设。

重复的代价

DRY 原则是这本书（以及 Pragmatic Programmer 传统）最出圈的遗产，也最常被误用。书里反对的从来不是「写了两次相似代码」，而是知识以多种表达形式存在——同一份规则散落在代码、注释、文档和口头约定里，每次修改都要四处同步。

这让我重新理解了「注释坏味道」：需要注释解释的代码往往不是缺注释，而是缺了一个诚实的命名。

最后

这本书最难得的地方是它不贩卖工具，只贩卖判断力。工具每五年换代，判断力二十年不过时——这本书就是证据。