1 · 读书笔记：代码整洁之道

Clean Code: A Handbook of Agile Software

https://book.douban.com/subject/34986245/

• 是什么（What）— 理论/原则，建立认知模型
• 为什么（Why）— 背后的动机、约束与权衡
• 怎么做（How）— 技巧 + 实践 + 边界（该做与不该做）

1.1 · 核心观点：

1. 是什么（What） 整洁代码不是“看起来优雅”这么简单，而是容易理解、容易修改、容易验证的代码。它通过清晰命名、单一职责、短小函数、稳定抽象和一致风格，把读者需要同时记住的上下文压到最低。整洁代码的核心不在语法技巧，而在是否尊重代码的可读性与意图表达。

2. 为什么（Why） 代码首先是写给人读的，其次才是给机器执行的。系统一旦进入持续迭代阶段，真正昂贵的不是第一次写出来，而是之后每一次修改、定位、扩展和协作。脏代码会让每次改动都变慢、变险、变得依赖个人经验；而整洁代码则通过降低认知负担，持续压低维护成本与沟通成本。

3. 怎么做（How） 实践上可以从几个层面推进：用准确命名减少歧义；让函数只做一件事并保持较少层级跳跃；避免重复、隐藏副作用、减少布尔开关和参数数量；让错误处理与主流程分离；通过测试保护行为，用重构改善结构。该做的是让代码意图一眼可见；不该做的是用注释掩盖坏命名、用“大而全”的函数堆逻辑、或以“先跑起来”为理由长期容忍混乱。

1.2 · 启发点（关键洞察）：

1. 整洁代码的本质不是“美学偏好”，而是降低理解成本。阅读成本一旦下降，修改速度和缺陷率通常都会一起改善。
2. 命名问题往往不是局部问题，而是建模问题。一个概念如果很难命名，通常意味着职责边界还没想清楚。
3. 函数越长、分支越深、参数越多，读者就越难在脑中维持稳定模型。复杂度常常不是来自算法，而是来自表达失控。
4. 注释不是越多越好。很多注释之所以存在，是因为代码本身没有把意图说清楚；优先修代码，再决定是否需要注释补充上下文。
5. 错误处理如果和正常流程纠缠在一起，主逻辑会迅速失焦。把异常路径显式隔离，代码的叙事性会明显提高。
6. 重复代码的问题不只是“多写了几行”，而是知识被复制后会在未来分叉，导致修改时不知道哪里才是真正的源头。
7. 整洁不是一次性整理，而是一种持续习惯。真正有效的方式不是等系统变烂再大扫除，而是在每次提交里顺手把周边变干净一点。
8. 好测试不仅验证代码正确，还会反过来约束设计。如果一个模块很难测试，通常也说明它耦合过重、职责过杂或边界不清。

1.3 · 行动：

1. 写函数前先问自己一句：这段代码是否只表达一个明确意图；如果不能，用提炼函数或重命名把意图拆出来。
2. 以后遇到模糊命名时，不再满足于“差不多能懂”，而是继续追问它代表的真实业务概念、边界和约束。
3. 对最近常改的模块做一次清洁检查，重点看重复逻辑、超长函数、过多布尔参数、隐藏副作用和错误处理与主流程混杂的问题。
4. 在 code review 里增加一条标准：这次改动是否让代码更容易读，而不只是“功能上可用”。
5. 修改旧代码时遵守 Boy Scout Rule：离开时让代码比进入时更整洁一点，哪怕只是顺手消灭一个坏命名或一段重复逻辑。
6. 对复杂流程优先用测试锁住行为，再重构结构，避免把“整理代码”变成高风险改写。

1.4 · 金句：

1. “Clean code reads like well-written prose.” — Grady Booch
2. “Indeed, the ratio of time spent reading versus writing is well over 10 to 1.” — Robert C. Martin
3. “You know you are working on clean code when each routine you read turns out to be pretty much what you expected.” — Ward Cunningham
4. “The proper use of comments is to compensate for our failure to express ourselves in code.” — Robert C. Martin
5. “Leave the campground cleaner than you found it.” — Boy Scout Rule