《代码整洁之道》

CH.01📚 书籍元信息

• 书名：《代码整洁之道》（Clean Code）
• 作者：Robert C. Martin（Bob 叔，敏捷宣言签署人之一）
• 类型：软件工程 / 编程实践
• 输入类型：仅书名（基于训练知识分析）

一句话总结：这本书回答了「如何让代码在长期维护中不腐化」的问题，答案是将整洁内化为开发者的肌肉记忆，让可读性成为代码质量的第一标准。

适读人群：

• 最需要：写了 1-5 年代码、开始接手遗留系统、准备带团队的开发者
• 反适读：追求「代码能跑就行」的速成型开发者（读完会更痛苦，因为知道标准却做不到）；不写代码的纯管理者（容易变成只提「整洁」要求却不懂成本的甲方）

CH.02🔍 真问题

核心问题： 代码的「编写成本」只占其生命周期的极小部分，但「阅读和维护成本」却占了绝大部分——为什么大多数团队仍然在写「只有作者能懂」的代码？如何让代码在作者离开后依然可维护？

旧答案：

• 「代码能运行就行，注释可以解释一切」
• 「效率优先，优化以后再说」
• 「只要文档写得好，代码乱一点无所谓」
• 「每个程序员的风格不同，代码不需要统一标准」

新答案： 代码的可读性不是「锦上添花」，而是「生存刚需」。整洁不是审美偏好，而是经济决策——代码被阅读的次数是被编写的数十倍，每一次阅读成本都在吞噬利润。应该把整洁视为一种开发纪律，像呼吸一样自然，而不是「有空再做的事」。

答案的底层逻辑： 软件的成本结构是「编写 10%，阅读 90%」。因此：

• 提高编写速度而牺牲可读性 = 节省 10% 成本，增加 90% 成本
• 整洁代码的短期成本（命名思考、函数拆分）是固定投资，长期收益（维护成本下降）是复利

作者的依据来自其数十年工业级项目经验，以及对遗留系统腐化过程的观察。

关键边界：

• 这套方法论在长期项目和团队协作场景中收益最大
• 对于一次性脚本、原型验证、明确不需要维护的代码，整洁的边际收益极低
• 在技术债务已经极高的遗留系统中，「从头整洁化」可能成本过高，需要渐进策略而非推倒重来

CH.03🗺️ 知识地图

（图说明：从命名出发，经函数、注释、格式、错误处理，到测试、设计、系统架构，最终收敛于整洁哲学的层次结构。）

CH.04💡 核心模型深度解析

模型一：命名即意图

模型定义 好名字 = 名字本身能回答「这是什么 / 这做什么 / 为什么存在」；坏名字 = 名字需要注释或上下文才能理解。命名质量与代码可读性呈正相关，命名是最低成本、最高杠杆的整洁手段。

（图说明：命名是代码意图的第一层表达，失败后只能靠注释补救，注释则引发腐化。）

原书论证 作者通过大量 before/after 对比展示：变量名 d 改为 elapsedTimeInDays 后，代码自解释性剧增。函数名 process 改为 calculateWeeklyBill 后，调用方无需阅读实现就能理解意图。核心论点：名字是代码中最频繁被阅读的元素，因此命名的投入产出比最高。

迁移场景

1. API 设计：接口命名直接决定调用方的理解成本。getUser() vs fetchData() — 前者可读，后者是黑盒
2. 数据库字段命名：flag vs is_active_subscription — 字段名成为「活文档」
3. 会议命名：周会叫「同步会」还是「交付检查会」— 命名决定参会者的心智准备

失效边界

• 极端短小的上下文：临时变量 i、j 在数学算法中比 rowIndex 更通用
• 命名能力不足时：强迫写好名字可能暴露更深层的理解不足，此时应先理解业务再命名
• 过度命名：在 lambda 表达式、链式调用中，强行给每个中间态命名反而降低可读性

改造方法 将命名从「编程技巧」升级为「团队语言」：建立领域术语表，让同一业务概念在代码、文档、对话中保持同名。

🟢 小白版 SOP

• 触发条件：每次写新变量、函数、类之前
• 执行步骤：
  1. 先用英语（或中文拼音）把意图说出来：「这个变量是干嘛的？」
  2. 把说出来的那句话缩短到 2-3 个词
  3. 如果觉得名字不够明确，说明你还没想清楚这个变量的职责
• 验证标准：不看上下文，只看名字，能猜对用途的准确率 > 80%
• 回滚机制：发现名字不好，当场改，不要「先跑通再说」

🟡 老手版 SOP

• 触发条件：CR（代码审查）时发现命名模糊，或自己写完一段代码后
• 执行步骤：
  1. 检查所有公开 API 的命名：是否暴露了内部实现细节？
  2. 检查布尔变量：是否以 is/has/should 开头？
  3. 检查「映射」：有没有 a 代表 accumulator 这种只有作者懂的缩写？
• 验证标准：新同事能在不看注释的情况下，仅通过名字理解函数职责
• 常见陷阱：用了「正确但不熟悉」的术语，团队其他人看不懂（如数学符号在业务代码中）

🔵 团队版 SOP

• 触发条件：新项目启动、新成员加入、领域术语变更
• 角色 × 步骤矩阵：
  • Tech Lead：维护领域术语表，定义命名规范
  • 开发者：遵循规范，发现歧义时主动提出
  • CR 审查者：命名问题是一票否决项
• 验证标准：术语表覆盖率 > 90%，新成员上手时「命名困惑」类问题 < 3 次/周
• 回滚机制：术语表错误时，先修正表，再批量修正代码

决策检查清单

• 这个名字是否需要注释才能理解？
• 删掉注释后，只看名字，业务人员能猜到用途吗？
• 同一概念在不同地方的名字是否一致？
• 布尔变量是否以 is/has/should/can 开头？
• 缩写是否在团队中通用？

内容种子

• 文章：「为什么你的代码需要一个术语表？」
• 课程：「命名训练：从 'temp' 到 '未结清账单金额' 的 10 次迭代」
• 咨询：「帮团队建立命名规范」

模型二：函数单一职责

模型定义 一个函数只做一件事 — 不是「一个功能」，而是「一个抽象层次上的一个动作」。函数体越短越好，嵌套越少越好，参数越少越好（最好 0-2 个）。函数是代码可读性的最小单元。

（图说明：函数能否用一句话描述是检验「是否做了一件事」的试金石，不能则继续拆分。）

原书论证 作者展示了数百行的「大函数」如何被拆解成若干 5-20 行的短函数，每个函数名字就是其功能的注释。核心论点：阅读代码时，函数名是跳板 — 好的函数名让读者「跳过」实现，只在需要时深入。

迁移场景

1. 文档写作：段落 = 函数，标题 = 函数名。好标题让读者「跳过」段落，只在需要时深入
2. 流程设计：SOP 文档拆成步骤，每个步骤是一个「函数」，职责单一
3. 团队分工：每个角色 = 一个函数，职责明确，输入输出清晰

失效边界

• 性能敏感代码：函数调用有开销，极端场景下过度拆分会影响性能
• 递归算法：拆分可能破坏递归结构的简洁性
• 数学推导：某些数学证明需要「一口气」写完，拆分会打断逻辑链

改造方法 将「函数单一职责」升级为「模块单一职责」：函数 → 类 → 模块 → 服务，每一层都问「它只做一件事吗？」。

🟢 小白版 SOP

• 触发条件：写完一个函数后
• 执行步骤：
  1. 数一数：这个函数有几件事在做？（能用几个动词描述？）
  2. 如果 >1 件事，用「提取函数」重构
  3. 检查行数：>30 行？大概率需要拆
• 验证标准：函数名能完整描述函数行为
• 回滚机制：拆完后测试通过，不通过则拆分粒度有问题

🟡 老手版 SOP

• 触发条件：CR 时发现函数职责不清晰
• 执行步骤：
  1. 检查函数内是否有「不同抽象层次」的代码混在一起
  2. 检查参数：>3 个？是否应该封装成对象？
  3. 检查副作用：是否在偷偷修改外部状态？
• 验证标准：函数可独立测试，不依赖特定调用顺序
• 常见陷阱：拆太细导致「函数爆炸」，阅读时要在十个函数间跳转

🔵 团队版 SOP

• 触发条件：代码库维护期、性能优化期
• 角色 × 步骤矩阵：
  • Tech Lead：定义函数长度标准（如 ≤50 行）
  • 开发者：写完后自查，超标则重构
  • CR 审查者：函数职责不清是阻断项
• 验证标准：函数平均长度 < 25 行，函数内嵌套层数 ≤ 2
• 回滚机制：过度拆分导致的「阅读跳转成本」高于收益时，合并相关函数

决策检查清单

• 这个函数能用一句话描述吗？
• 函数行数 > 30？是否需要拆？
• 参数 > 3 个？是否应该封装？
• 函数内是否有「做 A 顺便做 B」的逻辑？
• 函数名字是否暗示了多个职责？

内容种子

• 文章：「30 行法则：为什么你的函数需要减肥」
• 课程：「函数拆分实战：把一个 200 行的函数拆成 8 个」
• 咨询：「代码库函数体检」

模型三：测试即设计

模型定义 测试代码不是「额外的负担」，而是代码设计的反馈回路 — 如果代码难以测试，说明设计有问题；测试代码本身也需要整洁，因为它也是「被阅读的代码」。

（图说明：测试与设计形成正反馈循环，测试难写是设计问题的信号。）

原书论证 作者提出 FIRST 原则：测试应该是快速（Fast）、独立（Independent）、可重复（Repeatable）、自验证（Self-Validating）、及时（Timely）的。核心论点：测试代码的整洁度等于生产代码 — 因为测试代码也是「文档」，描述了系统的预期行为。

迁移场景

1. 产品验收：验收标准（Acceptance Criteria）= 测试用例，清晰的验收标准倒逼清晰的需求
2. 流程审计：流程测试 = 检查点设计，「如果这个环节出问题，怎么快速发现？」
3. 学习评估：学习测试 = 练习题设计，好的练习题倒逼好的知识结构

失效边界

• 探索性编程：前期不确定方向时，强制写测试会阻碍探索
• 算法研究：纯数学证明场景，测试不是核心验证手段
• 遗留系统：已有系统的测试可能需要特殊工具（如录制回放），不适用 TDD

改造方法 将「测试即设计」扩展为「可验证性即设计标准」：任何交付物（代码、文档、流程）都应问「怎么验证它做对了？」。

🟢 小白版 SOP

• 触发条件：写完功能代码后
• 执行步骤：
  1. 写一个最简单的测试：输入 X，期望输出 Y
  2. 运行测试，通过 → 继续；不通过 → 修代码
  3. 每次改代码前，先写一个「失败的测试」
• 验证标准：测试能描述函数的核心行为
• 回滚机制：测试太难写？说明函数职责不单一，先重构函数

🟡 老手版 SOP

• 触发条件：代码难以测试时
• 执行步骤：
  1. 诊断：是函数职责不单一？依赖太多？状态太杂？
  2. 重构设计：提取接口、注入依赖、分离状态
  3. 重构后重新尝试写测试
• 验证标准：测试不依赖特定执行顺序、不依赖外部服务、毫秒级完成
• 常见陷阱：为了覆盖率而写「无意义的测试」（如只测 getter）

🔵 团队版 SOP

• 触发条件：新功能开发、Bug 修复
• 角色 × 步骤矩阵：
  • 开发者：先写测试，再写代码（TDD）
  • QA：关注端到端测试，与单元测试互补
  • Tech Lead：监控测试覆盖率，> 80% 为健康
• 验证标准：新功能测试覆盖率 > 90%，回归测试 < 5 分钟
• 回滚机制：测试维护成本高于收益时，评估是否过度测试

决策检查清单

• 测试能描述函数的核心行为吗？
• 测试是否快速（毫秒级）？
• 测试是否独立（不依赖其他测试）？
• 测试是否自验证（不需要人工判断）？
• 测试代码是否也需要整洁命名？

内容种子

• 文章：「测试难写是设计问题的信号」
• 课程：「TDD 实战：从 Red-Green-Refactor 开始」
• 咨询：「代码库测试体检」

模型四：整洁层次结构

模型定义 整洁有层次：命名 → 函数 → 类 → 模块 → 系统。低层整洁是高层整洁的前提 — 如果函数名都是 temp，系统架构再优雅也没用。整洁是「从下往上」长出来的，不是「从上往下」设计出来的。

（图说明：整洁是自下而上的积累，底层混乱会向上腐化，底层整洁支撑高层优雅。）

原书论证 作者在书中按这个层次组织章节：先讲命名，再讲函数，再讲类，再讲系统。核心论点：大多数整洁讨论都只谈架构，但真正的战场在函数级别。架构可以推倒重来，但函数级别的腐化是「温水煮青蛙」。

迁移场景

1. 组织管理：个体素养 → 团队规范 → 部门文化 → 公司制度，底层不扎实，上层制度是空中楼阁
2. 写作：用词 → 句子 → 段落 → 章节 → 书，好文章是「句子级别」的整洁累积
3. 学习：概念清晰 → 推理正确 → 体系完整 → 应用自如，基础概念模糊时，高阶应用必然出错

失效边界

• 遗留系统重构：可能需要从上往下「绞杀者模式」渐进替换，不能等底层改完
• 资源极度有限时：先保核心模块整洁，允许边缘模块暂时凌乱

改造方法 将「整洁层次」用于「技术债优先级排序」：评估技术债时，按层次打分，优先修复低层技术债。

🟢 小白版 SOP

• 触发条件：接手新代码库时
• 执行步骤：
  1. 先看命名质量：名字是否自解释？
  2. 再看函数长度：是否 > 50 行？
  3. 再看类职责：是否 > 1 个职责？
  4. 按层次修复，不要一上来就重构架构
• 验证标准：能读懂单个函数的意图，不需要看完整上下文
• 回滚机制：发现命名问题太多？先建术语表，再逐个修正

🟡 老手版 SOP

• 触发条件：代码审查、技术债评估
• 执行步骤：
  1. 按层次评估：命名债、函数债、类债、模块债、系统债
  2. 优先修复低层债（投入产出比最高）
  3. 记录高层债，作为长期重构目标
• 验证标准：每次重构后，代码「可读性评分」提升
• 常见陷阱：被高层架构问题吸引，忽视底层混乱

🔵 团队版 SOP

• 触发条件：Sprint 评审、技术债盘点
• 角色 × 步骤矩阵：
  • Tech Lead：定义各层次整洁标准
  • 开发者：按标准自评，记录技术债
  • 团队：按层次排优先级，低层优先
• 验证标准：技术债清偿率 > 20%/Sprint
• 回滚机制：发现修复低层债时引入新问题？暂停，先评估影响

决策检查清单

• 命名质量是否达标？
• 函数是否职责单一？
• 类是否只有一个变化原因？
• 模块依赖是否清晰？
• 系统架构是否「从下往上」长出来？

内容种子

• 文章：「整洁不是架构问题，是函数问题」
• 课程：「代码体检：从命名到系统的五层诊断」
• 咨询：「技术债优先级排序」

模型五：重构即思考

模型定义 重构不是「改代码」，而是「通过改代码来加深理解」。重构是思考的手段，不是思考的结果。不理解就不重构，重构的过程就是理解的过程。

（图说明：重构是「读不懂→改一点→再读→懂一点」的循环，而非一次性改造。）

原书论证 作者反复强调「童子军军规」：离开时让代码比来时更整洁。核心论点：不要等到「重构日」再重构，每次触碰代码都是一次整洁化的机会。大规模重构失败率极高，小步重构才能持续。

迁移场景

1. 知识整理：每次复习笔记时，顺便优化笔记结构 — 重构知识库
2. 流程优化：每次执行流程时，记录可改进点，下次执行时微调 — 重构流程
3. 关系维护：每次互动后，反思「哪里可以做得更好」— 重构关系模式

失效边界

• 紧急修复：线上事故时不要重构，先止血
• 不理解系统时：强行重构可能引入新 Bug
• 重构瘾：过度重构导致「永远在改，永远没交付」

改造方法 将「童子军军规」扩展到所有知识工作：每次处理文档/邮件/笔记时，花 2 分钟让它比原来更好。

🟢 小白版 SOP

• 触发条件：修改任何代码之前
• 执行步骤：
  1. 先读代码，标记「看不懂」的地方
  2. 先重构看不懂的地方，让它变清楚
  3. 再加新功能
• 验证标准：重构后，代码「看不懂」的地方减少了
• 回滚机制：重构后测试不通过？回滚，等想清楚再改

🟡 老手版 SOP

• 触发条件：CR 时、Bug 修复后、功能开发间隙
• 执行步骤：
  1. 每次触碰代码，识别 1-2 个可改善点
  2. 小步修改，保持测试通过
  3. 提交时在 commit message 中记录「整洁化」内容
• 验证标准：每周代码整洁度 > 上周
• 常见陷阱：重构上瘾，功能交付延迟

🔵 团队版 SOP

• 触发条件：Sprint 回顾、代码审查、技术债盘点
• 角色 × 步骤矩阵：
  • 开发者：遵循童子军军规，每次提交净整洁度 > 0
  • CR 审查者：检查是否有「整洁化」提交
  • Tech Lead：追踪整洁度趋势
• 验证标准：代码整洁度指标（如函数平均长度）持续改善
• 回滚机制：整洁化引发新问题？记录，评估是否需要回滚

决策检查清单

• 修改代码前，是否先读了现有代码？
• 读的过程中，是否标记了「看不懂」的地方？
• 重构后，是否确保测试通过？
• 每次提交，代码是否比之前更整洁？
• 是否避免了「大规模重构」的诱惑？

内容种子

• 文章：「童子军军规：代码整洁的最小可行习惯」
• 课程：「重构实战：在不改功能的前提下改善代码」
• 咨询：「团队代码整洁度趋势追踪」

CH.05🧠 费曼检验

情境问题（综合应用）

你是一个 5 人团队的 Tech Lead，团队刚接手一个 3 年前的遗留系统，代码库 10 万行，没有测试，函数平均长度 80 行，变量名充斥 a、b、temp、data。现在产品要求在 3 个月内上线新功能，你怎么平衡「整洁化」和「交付压力」？

参考解法框架：

1. 用「整洁层次结构」诊断：先评估哪一层最混乱（通常是命名和函数）
2. 用「重构即思考」策略：不搞大规模重构，遵循童子军军规，每次改动顺手整洁化
3. 用「函数单一职责」作为新功能代码的标准：新代码必须整洁，老代码渐进改善
4. 用「测试即设计」：新功能必须有测试，老代码在修改时补测试
5. 用「命名即意图」：新功能代码命名必须清晰，老代码在触碰时改名

好的回答应包含的要素：

• 不是「先整洁化再开发」，而是「整洁化嵌入开发流程」
• 有优先级：先保新功能交付，老代码按触碰频率渐进改善
• 有度量：追踪代码整洁度趋势
• 有取舍：接受某些老代码暂时不整洁

5 个常见误解

1. 误解：「代码整洁 = 代码完美」 澄清：整洁是持续改善的过程，不是终点。接受「今天整洁，明天可能需要再次整洁」。

2. 误解：「整洁代码运行更慢」 澄清：整洁代码通常性能相当或更好（因为逻辑清晰，优化更容易）。性能问题应在 Profile 后针对性解决，而非以「性能」为借口写烂代码。

3. 误解：「整洁标准是固定的」 澄清：整洁标准因团队、项目、语言而异。关键不是「符合某个标准」，而是「团队对标准有共识」。

4. 误解：「重构需要专门的时间」 澄清：专门的「重构 Sprint」失败率极高。最好的重构是「每次改动都顺手整洁化」，积少成多。

5. 误解：「整洁只影响开发效率」 澄清：整洁影响的是「全生命周期成本」，包括维护、交接、调试、扩展。短期看是成本，长期看是投资。

12 岁孩子版

第一件事：这本书讲的是「怎么让代码好读」，就像写作文要让别人看得懂一样。 第二件事：以前大家觉得代码只要能运行就行，写得乱一点没关系，反正电脑不看字。 第三件事：但作者发现，代码写完之后，人类要读它的次数是写它的几十倍，所以「好读」比「能运行」更重要。 第四件事：所以你可以这样用：每次写完代码，检查名字是不是清楚、函数是不是太长、有没有做太多事。 第五件事：但要注意，整洁不是一次搞定的事，而是每次碰到代码都让它好一点点，慢慢积累。

CH.06📝 全书评估

1. 真正解决了什么问题？ 解决了「代码在长期维护中如何不腐化」的问题，提供了从命名到系统架构的全层次整洁方法论。不只是「怎么写好代码」，更是「怎么让代码库持续保持可维护」。

2. 核心模型原创性如何？ 单一模型原创性中等（命名、函数拆分等概念前人已有论述），但系统化整合的原创性高 — 将散落的编程智慧整合成「整洁层次结构」，形成了可执行的方法论体系。

3. 证据质量如何？ 主要基于作者个人工业经验（Fortune 500 公司项目），缺乏大规模对照实验。但作为「实践智慧」类书籍，经验性证据的权重是合理的。

4. 最大盲区是什么？

• 几乎不讨论「整洁的成本」— 命名思考、函数拆分、重构都消耗时间，书中没有给出「整洁的 ROI 分析框架」
• 假设开发者有时间「做整洁」，但在高压交付场景下，这个假设经常不成立
• 对「整洁的政治性」讨论不足 — 整洁标准可能引发团队冲突（如「你命名太差」）

CH.07🔗 跨书关联

与《重构：改善既有代码的设计》的关联

• 共振点：两本书都认为「代码需要持续改善」，Martin Fowler 的《重构》提供了具体的重构手法，Robert C. Martin 的《整洁之道》提供了「为什么要做」和「整洁的哲学」
• 冲突点：《重构》更「中性」（重构是技术行为），《整洁之道》更「价值导向」（整洁是道德义务）— 这种价值判断可能引发争议
• 为什么接着读：读完《整洁之道》理解「为什么整洁」，再读《重构》学习「怎么整洁」，两本书互补

与《设计模式：可复用面向对象软件的基础》的关联

• 共振点：两本书都认为「好的设计有规律可循」，设计模式是系统级整洁的具体方案
• 冲突点：《整洁之道》警告「不要过度使用模式」，而初学者容易把设计模式当成「整洁的银弹」
• 为什么接着读：读完《整洁之道》理解「整洁的哲学」，再读《设计模式》学习「具体的设计套路」，但要警惕「为了模式而模式」

与《人月神话》的关联

• 共振点：两本书都认为「软件开发的核心挑战是人与沟通」，代码整洁本质上是「降低人与代码的沟通成本」
• 冲突点：《人月神话》更宏观（项目管理视角），《整洁之道》更微观（代码视角）
• 为什么接着读：读完《整洁之道》理解「代码层面的沟通成本」，再读《人月神话》理解「项目层面的沟通成本」，形成全景视角

知识网络位置

• 上游（先读）：《程序设计实践》（Kernighan & Pike）— 更基础的编程规范
• 下游（再读）：《重构》（Martin Fowler）→ 《设计模式》 → 《架构整洁之道》（Robert C. Martin）— 从函数整洁到架构整洁
• 对照读：《人月神话》（Fred Brooks）— 从代码整洁到项目管理

CH.08✨ 深度洞察摘录

命名是代码可读性的最大杠杆

• 来源：《代码整洁之道》第 2 章「有意义的命名」
• 类型：可迁移模型
• 核心内容：代码中被阅读最频繁的元素不是逻辑，而是名字。好名字让读者「跳过」实现，直接理解意图。坏名字则让读者必须读完代码才能理解变量/函数的含义。命名是最低成本、最高杠杆的整洁手段。
• 可迁移到：API 设计（接口命名）、文档写作（标题命名）、数据库设计（字段命名）、团队管理（会议/项目命名）

代码是写给人读的，顺便给机器执行

• 来源：《代码整洁之道》核心哲学
• 类型：认知颠覆
• 核心内容：大多数开发者认为代码的主要读者是编译器/解释器，因此「能运行」是第一标准。但事实上，代码的主要读者是人（包括未来的自己），「能理解」才是第一标准。这个认知转变是整洁代码的前提。
• 可迁移到：任何知识工作 — 写文档、做汇报、建流程，第一读者是人，不是机器

测试难写是设计问题的信号

• 来源：《代码整洁之道》第 9 章「单元测试」
• 类型：可迁移模型
• 核心内容：如果一个函数/模块难以测试，通常不是「测试方法有问题」，而是「设计有问题」— 职责不单一、依赖太紧耦合、状态太混乱。测试是设计质量的「试纸」，测试难 = 设计烂。
• 可迁移到：流程审计（流程难审计 = 流程设计有问题）、文档编写（文档难写 = 知识结构有问题）、学习评估（练习难设计 = 知识理解不够深）

童子军军规：每次离开时比来时更整洁

• 来源：《代码整洁之道》第 1 章「整洁代码」
• 类型：金句级表达
• 核心内容：不要等到「重构日」再重构，每次触碰代码都是一次整洁化的机会。大规模重构失败率极高，小步重构才能持续。这个习惯的累积效应远超一次性大改造。
• 可迁移到：知识整理（每次复习笔记时顺手优化）、流程优化（每次执行时记录改进点）、关系维护（每次互动后反思）

整洁不是审美偏好，是经济决策

• 来源：《代码整洁之道》全书论点
• 类型：认知颠覆
• 核心内容：整洁代码的短期成本（命名思考、函数拆分）是固定投资，长期收益（维护成本下降、交接成本下降、调试成本下降）是复利。整洁是「节省 90% 阅读成本」的手段，不是「让代码好看」的审美行为。
• 可迁移到：任何需要「长期维护」的资产 — 文档、流程、系统、知识库，短期整洁化投入 = 长期维护成本降低