《程序员修炼之道》9 条核心工程理念，读懂务实开发思维

• 1. DRY：知识唯一源头，不只是代码文本不重复
• 2. 破窗理论：小问题被放任，质量标准就会下降
• 3. 正交性：模块独立，改动隔离
• 4. 曳光弹：先打通端到端骨架，再持续扩展
• 5. 一次性原型：用低成本实验消除不确定性
• 6. 按契约设计：把隐含假设写清楚
• 7. 警惕巧合式编程：能跑不等于正确
• 8. 迪米特法则：只和直接朋友对话
• 9. 够好即可：把质量作为需求来权衡
• 收尾：让系统更容易变更

很多程序员的学习路线，是先啃 GoF 设计模式，再学框架、刷算法，却常常忽略一本经典：《程序员修炼之道：通向务实的最高境界》（The Pragmatic Programmer）。

它的重点不是语法、API 或某个具体框架，而是程序员如何思考、如何权衡，以及如何规避项目里那些不容易察觉的工程陷阱。它提供的是一套工程决策与思维体系，其中许多原则，在日常写代码、做架构和推进项目时都能反复使用。

下面整理 9 条核心理念。文中的例子和归纳是对这些思想的实践解读，不是书中原文的逐字摘录。

1. DRY：知识唯一源头，不只是代码文本不重复

DRY 的全称是 Don’t Repeat Yourself。很多人把它理解成“不要复制粘贴代码”，但它真正关心的是：系统中的每一份知识，都应该有唯一、明确、权威的表示。

重复的根源不一定是复制代码：

• 同一个业务规则，在前端、后端和数据库中分别维护，变更时需要人工同步；
• 相同配置散落在多个 YAML 文件和硬编码常量中；
• 文档、注释和代码分别描述同一个逻辑，却已经出现版本差异。

这些知识副本一旦失去同步，就容易造成不一致的行为。更合理的做法，是明确规则的权威来源，再通过生成、共享配置或自动校验保持一致。

这里需要区分：多层校验本身并不等于应该消除的重复。前端校验改善交互，后端校验守住信任边界，数据库约束保护数据完整性。不能为了 DRY 删掉必要的防线，应该减少的是同一规则在各处独立维护的成本。

反过来，两段代码即使长得一样，只要表达的是不同业务知识、未来可能独立变化，也不必急着抽象到一起。

代码可以生成，也可能出现重复；同一份业务知识应当有明确的权威来源。

2. 破窗理论：小问题被放任，质量标准就会下降

书中借用“破窗”来类比软件腐烂。一处无人处理的临时方案、一段注释掉的废弃代码、一个长期被忽略的警告，都可能向团队传递同一个信号：这里的质量问题可以不管。

一旦这种做法成为惯例，后来者就更容易继续堆砌临时代码。问题不仅是那一处代码不好看，更是团队逐渐降低了对整个系统的要求。

处理破窗，并不意味着每次发现问题都要启动大规模重构。可以根据影响选择：

• 能在当前范围内安全修复，就及时修复；
• 暂时无法修复，就隔离影响，记录原因和后续处理责任；
• 已经失效的代码、注释和配置，及时清理。

不是要求一次修完所有问题，而是不要让“放着不管”成为默认选择。

3. 正交性：模块独立，改动隔离

正交性的核心目标是：修改一个组件，不会意外影响其他无关组件。

判断一个系统的正交性，可以问：改 A 模块时，需要修改多少本来不应该相关的地方？

• 正交性较好：替换数据库访问实现，业务接口保持稳定；更换第三方 SDK，主要修改适配层。
• 耦合严重：存储层一个内部字段改名，页面、业务服务和运维脚本都要跟着修改，因为它们直接依赖了存储细节。

当然，一个业务字段的含义真的变了，模型、接口、页面和测试一起调整，可能是合理的需求传播。改动文件多，并不能单独证明系统设计差；关键是这些依赖是否必要。

减少共享可变状态、通过参数显式传递依赖、明确接口边界，都有助于提高正交性。它的价值，是把变化控制在应当变化的范围内。

4. 曳光弹：先打通端到端骨架，再持续扩展

曳光弹开发（Tracer Bullet Development）强调：先实现一条完整、端到端、可运行的最小链路，再沿着这条链路迭代。

它不是临时演示代码。这个骨架需要具备可以继续演进的质量，后续功能会逐步加入其中，最终成为正式系统的一部分。

例如开发下单功能，可以先实现：

前端提交订单 → API 接收请求 → 写入数据库 → 返回结果 → 页面展示

第一轮可以暂不实现库存、支付和优惠券，但要真正打通各层之间的连接，验证接口、数据流和集成方式是否可行。涉及真实交易的必要约束，仍须在正式交付前补齐。

这种方式能更早暴露集成问题。如果先写完全部数据库模型，再写全部接口，最后才接前端，往往要到很晚才能确认各层是否能协同工作。

优先完成一条薄薄的垂直切片，让系统尽早运行起来，再扩展业务能力。

5. 一次性原型：用低成本实验消除不确定性

原型与曳光弹的区别，在于实验的目标和代码的去向。

一次性原型的目的，是获得知识，而不是积累正式产品代码。它可以验证某个技术方案，也可以探索交互设计、性能瓶颈或架构选择，不必覆盖完整业务链路。

实践中，团队也常用 Spike 指有明确时间边界的探索任务。Spike 可以借助原型完成，也可能产出调研结论、性能数据或方案比较，不必把它严格等同于某一种代码形式。

例如，想确认某个解析库能否处理目标文件，可以用少量代表性样本快速试验。这个阶段不必实现完整的用户管理、日志系统和异常处理，但应当明确样本范围和结论的适用条件。

最常见的坑，是把“实验跑通了”当成“产品可以上线了”。缺少必要校验、错误处理和维护结构的原型直接进入生产，很容易成为下一扇破窗。

6. 按契约设计：把隐含假设写清楚

按契约设计（Design by Contract，DbC）把模块之间的约定分为三类：

• 前置条件：调用方在调用前必须保证什么；
• 后置条件：满足前置条件后，操作完成时承诺什么；
• 不变量：对象在约定的可观察边界上必须保持的约束。

例如，一个从账户扣款的方法，可以约定金额必须为正、可用余额足够；成功后，余额应减少对应金额；账户对外可见时，可用余额不能为负。方法内部更新状态时可能存在短暂的中间状态，所以“不变量”不宜简单理解为每一条内部语句执行时都绝不能暂时破坏。

契约的作用，是减少“我以为你会传正确参数”“我以为失败后状态不会变”这类隐含假设。

当内部契约被违反时，应尽早暴露错误，避免带着错误状态继续运行。但用户输入无效、网络超时等预期内情况，仍需要明确的错误返回和恢复策略。Fail Fast 不等于遇到任何错误都终止整个服务。

断言、类型约束、参数检查和测试都可以帮助表达或验证契约；面对不可信的外部输入，不能只依赖可能被关闭的断言。

7. 警惕巧合式编程：能跑不等于正确

巧合式编程的典型表现是：代码碰巧运行成功，但你不理解它成功所依赖的条件。

复制一段代码，调几个参数，看到测试能跑就提交；不知道接口的保证范围，也没有确认数据、顺序和并发条件。环境稍有变化，问题就可能暴露出来。

例如，一个查询在本地总是按照插入顺序返回结果，于是业务代码默认结果天然有序。如果没有明确的排序约定，这种依赖就建立在偶然表现之上。

避免巧合式编程，可以在提交前问自己：

• 这段代码为什么能工作，依据是文档约定，还是一次观察？
• 哪些假设已经通过代码、类型或测试表达出来？
• 输入为空、规模变大或并发发生时，结论是否仍然成立？

务实的开发，不只是把程序调到能跑，还要理解它在什么条件下可靠。

8. 迪米特法则：只和直接朋友对话

迪米特法则（Law of Demeter）也叫最少知识原则。它强调，一个对象应尽量只与直接相关的对象交互，例如自己、传入的参数、自己创建的对象和直接成员。

典型问题是沿着对象关系一路访问内部结构：

order.customer.account.settings.currency

调用方为了获得一个币种，却需要知道订单、客户、账户和设置之间的完整组织方式。中间任何一层改变，都可能影响这个调用方。

更合适的做法，是让承担相关职责的对象提供稳定接口，例如由订单或定价服务提供结算币种，减少调用方对内部结构的了解。

不过，不能仅凭链式调用里有几个点，就断定违反了迪米特法则。流式 API、构建器和数据转换链可能本来就是公开接口的设计方式。真正需要检查的是：调用方是否依赖了不该知道的内部对象关系。

这条法则与正交性相呼应：减少不必要的知识，才能减少不必要的联动修改。

9. 够好即可：把质量作为需求来权衡

工程师很容易陷入完美主义：反复打磨抽象，提前优化尚未出现的瓶颈，为未来可能发生的需求增加复杂度，却迟迟无法交付。

“够好即可”的意思是：结合业务目标，与相关方明确当前版本需要达到的质量标准。

它不是粗制滥造，也不是由开发者单方面决定降低标准。安全、正确性和可靠性要求需要根据具体场景确定；在这些边界内，再对功能范围、时间、性能和维护成本做取舍。

例如，一个内部报表工具，当前可能只需要稳定支持十位同事使用，不必一开始就建设面向百万用户的基础设施。但数据计算必须正确，必要的访问控制也不能因为用户少就省略。

可以在开发前明确：

• 这一版本必须解决什么问题？
• 哪些质量指标是验收底线？
• 哪些能力可以等获得实际反馈后再补充？

有了可讨论的交付标准，团队才能避免把“还可以更好”变成无限延期的理由。

收尾：让系统更容易变更

把这 9 条原则放在一起，可以看到一个共同方向：让系统更容易变更（Easier To Change）。

好代码不要求我们一次性设计出完美架构，而是要求我们持续做出有依据的工程决策：

• 用 DRY 控制知识重复；
• 及时处理破窗，维持质量标准；
• 用正交性和迪米特法则隔离改动影响；
• 用曳光弹和原型，以适合的方式验证方案；
• 用契约明确模块之间的责任；
• 理解代码的成立条件，拒绝依赖巧合；
• 定义“够好”的标准，在约束中完成交付。

它与 GoF 设计模式相互补充：GoF 侧重类和对象如何组织，《程序员修炼之道》则帮助我们思考，面对真实的工程问题，应该如何判断和取舍。

原文链接： 《程序员修炼之道》9 条核心工程理念，读懂务实开发思维 ，转载请注明来源！