先定关注顺序
评审时间有限，如果从命名和格式看起，注意力会在真正重要的地方耗尽。建议按正确性、可维护性、风格这样的顺序推进，风格问题尽量交给自动化工具处理。人的精力应当花在机器判断不了的地方。
正确性包括边界处理、并发安全、错误分支是否覆盖。可维护性包括职责划分是否清晰、依赖方向是否合理、未来修改是否要动多处。这两类问题一旦进入主干，修复成本会随时间快速上升。
把顺序写进团队的评审约定，评审者就有了共同的检查路径，也减少了对同一份代码反复提出不同层次意见的情况。约定不必复杂，哪怕只是三行说明，也能让新成员的评审有章可循。顺序公开之后，作者也能预判会被问到什么。
评论要指向代码而非人
同样一句话，换一种说法，接受度差别很大。与其问你为什么这么写，不如说这里在数据为空时可能报错，建议加一层判断。前者要求对方辩护，后者直接给出问题与方向。评审评论应当包含判断依据，而不只是结论。 给出依据，对方即使不同意，也能在同一个层面上讨论。
对于纯偏好类意见，应当明确标注为建议而非要求，并说明是否阻塞合并。把必须改和可以商量区分开，能显著减少来回沟通，也能避免作者在非关键点上消耗时间。风格分歧可以留到规范层面统一解决。
作者也需要承担说明义务。改动如果涉及不明显的历史原因，应当主动在描述里写清背景，避免评审者反复猜测意图。描述写得清楚，评审就能直接聚焦在判断上。
控制单次评审规模
一次几百行的改动，评审质量必然下降。较可行的做法是把单次评审控制在一个人能在半小时内认真读完的规模，超出部分拆成多次提交。评审规模是质量的上限，而不是效率的敌人。
拆分要按逻辑单元而非按文件。一次提交只做一件事，重命名与功能修改不要混在一起，否则差异难以阅读，也容易漏掉问题。差异视图对混合改动的识别能力其实很有限。
如果确实无法拆分，例如自动生成的内容或大规模格式化，应当在描述中说明，并约定只重点检查其中一小部分。提前说明可以避免评审者在无关差异上花费时间，也避免评审流于形式。
用评审沉淀共识
评审中反复出现的同一类问题，说明它不是个人失误，而是缺少约定。把这类问题记录下来，转化为规范条目或检查工具，才能真正减少重复发生。同一类问题出现三次以上，就值得考虑用工具拦住。
可以做一份简短的历史问题清单，列出团队踩过的坑与对应写法。新成员读一遍，比看十条抽象规范更有效。评审的长期收益是形成团队共识，而不仅是通过某次改动。
最后要注意节奏。积压多日的评审会阻塞他人，也会让改动越滚越大。约定响应时间，哪怕只是先给出初步意见，也比长时间没有反馈更有帮助。响应及时本身就是对协作的保护。
