笔记 02｜注重实效的途径：把原则变成可执行的习惯

一、核心观点
第二章把"态度"翻译成"做法"，给出了七组可以日常执行的原则。

1. DRY——不要重复你自己。重复不只是复制粘贴的代码，还包括重复的知识：同一业务规则散落在前端校验、后端接口、文档三处，才是最难维护的重复。判断标准是：这处改动是否需要同时修改多份表达。
2. 正交性。两个模块正交，意味着改动 A 不会牵连 B。作者给出的实践建议非常具体：避免全局数据、避免相似函数、保持层次清晰、用组合代替继承。正交性带来的直接收益是可测试性与可替换性。
3. 可撤销性。不要把架构选择当成不可逆的终身契约。用"有没有退路"来评估方案：接口抽象、数据迁移脚本、灰度开关，都是在为未来保留余地。
4. 曳光弹与原型。曳光弹是端到端打通的一条窄路径，它要保留并演化；原型是为了学习而快速丢弃的探索，它注定要被扔掉。二者容易混淆，混淆的代价是拿原型当产品。
5. 靠近问题域编程。用领域语言命名，让代码读起来像业务陈述，而不是像数据结构操作手册。DSL 不是炫技，而是降低沟通成本。
6. 估算。"大概要三天"是该被抵制的表述。作者建议给出带单位与置信度的区间，并记录估算、事后复盘，逐步校准自己的"估算误差曲线"。

二、原文摘录

"在一个系统中，每一项知识都必须有一个单一的、权威的、无歧义的表示。"

"曳光弹照亮了通往目标的道路。"

"要做估算，先问'单位是什么？'"

三、个人思考

DRY 常被误读为"少写代码"，其实它约束的是知识的唯一来源。我在项目里见过最严重的重复不是代码，而是"权限规则"：数据库里一套、前端按钮上写死一套、运营文档里又一套，最后谁都不知道以哪套为准。按 DRY 的标准，应该把权限表达成一处可执行的规则，让其他三处都从它派生。

正交性则让我重新审视"公共工具类"。很多被称作复用的模块，实质是把无关功能捆在一起，反而破坏了独立性。好的复用应该是能力的组合，而不是耦合的捷径。

四、行动清单

找一个重复出现的业务规则，把它收敛到单一实现，其余位置改为调用。
在下一个任务中先画一条曳光弹路径（端到端最小闭环），再铺开细节。
估算时统一使用"区间 + 概率"格式，例如"5～8 天，70% 把握"。
复盘一次历史估算偏差，计算自己的平均倍数。