代码评审的节奏感：为什么小步提交更容易被合并

大提交的隐性成本

一次改动涉及三十个文件时，评审人很难在有限时间里建立完整上下文。结果通常是两种：草率通过，或者反复来回。前者留下隐患，后者拖慢节奏。

小步提交把认知负担摊开。每次只看一个明确意图的改动，评审人容易判断对错，作者也更容易根据反馈调整方向。

怎么切分才算合理

切分的依据是意图而不是文件。重构与功能改动分开，格式化与逻辑修改分开，依赖升级单独成一次。这样即使某次改动需要回滚，也不会牵连无关代码。

如果一次改动确实无法拆小，可以在描述里写清阅读顺序，把核心文件标出来，降低评审人的进入成本。

描述比代码更需要用心

好的提交描述回答三个问题：为什么改、改了什么、怎么验证。把背景写清楚，评审人就不必靠猜。涉及取舍时，说明放弃的方案同样有价值。

对于界面或行为变化，附上前后对比比文字描述更直接。对于性能相关改动，给出测量方法与结果，避免凭感觉争论。

让评审成为对话

评审意见分两类：必须修改与建议讨论。作者需要明确区分，避免把讨论性意见当成阻塞项，也避免把必须修改的问题搁置。

团队层面可以约定响应时间，例如工作日当天给出首次反馈。节奏稳定之后，评审不再是瓶颈，而是知识流动的通道。

评审文化的形成

评审质量取决于团队是否把提出问题视为帮助而非指责。措辞上，用提问代替断言，例如「这里是否考虑过并发」比「这里写错了」更容易被接受。

对新人而言，前几次评审的经历会影响长期习惯。安排有经验的评审人带一带，比写在规范里更有效。