共计 1573 个字符，预计需要花费 4 分钟才能阅读完成。
评审目标
代码评审的目标就是为了保障公司整体代码的健康状况随着一直迭代，始终保持一个较高的程度，所有在评审中应用的工具和流程都应是为此目标而设计的。
评审准则
- 激励质疑
- 放弃代码格调，恪守开发标准
- 优先设计准则，尊重集体偏好
- 器重每一行代码
- 尽可能采纳面对面的模式
评审机会
研发流程应该是紧密的、有节奏的，而个体的代码品质会影响整体交付进度，所以请 第一工夫 启动代码评审，最晚不要超过晚期测试阶段。
如果是异步评审的机制，评审过程最好不要超过一个工作日，如果评审工夫较长，请在开始评审时进行初步反馈。
评审范畴
1. 性能
这个 Change List 是否达到了预期指标？
并发、数据权限、性能、竞态条件等一系列边缘异样是否正当躲避？
2. 复杂性
新增的简单是否是值得的？
简单设计的实现是否是可读的？
形象定义是否是优雅整洁的？
激励通过设计进步可扩展性，但不可“面向未来做设计”，二者之间的界线应该是：是否可能看到明确的演进方向（actual shape）和需要
3. 单元测试
是否有单元测试？
单元测试是否具备良好的可读性？
每一个测试是否有断言？
是否能笼罩尽可能多的逻辑分支？
4. 命名
命名是否符合规范，且具备良好可读性？
命名是否能 充沛 表白一个项是什么、用来做什么？
5. 正文
正文内容是否是必须的？
正文信息是否全面表述对应代码的意义？如果发现正文难以解释这段代码，那么很大概率上这段代码应该简化或者重构。
正文信息应表白代码的用途，而不是解释代码在干什么
6. 代码格调
激励对代码格调提出改良倡议，但请提及这是一项精益求精的倡议，切不可作为评审通过与否的断定条件。
如果应用评审工具，请在评论前标注 Nit:，以标识这是一项 Nitpick（求全责备）的倡议。
7. 文档
是否同时建设了或批改了相干文档？
文档格局是否与原我的项目保持一致？
8. 上下文
批改的内容是否影响原业务逻辑的上下游依赖？
批改的内容是否导致代码品质降落，甚至零碎架构腐化？
9. 优良的代码设计
请不要疏忽 change list 中你感觉不错的局部，必定优良设计比指出谬误更有价值。
评审尺度
不要为了进步评审速度而就义代码评审的规范，团队内的代码评审应该是一个继续改良的过程，发现问题、解决问题、防止问题，这种正向循环会为研发流程的每一步都带来收益。
如果因为各种起因的确须要减速评审环节，能够依照重要水平升高一部分评审规范。但请在适合的工夫，对这部分代码进行从新评审，我的项目进度缓和不应成为升高代码品质的理由。
如何解决评审意见抵触
评审是对别人工作进行评判，难以避免意见相左的状况产生，通常研发人员会有十分多的理由回绝评审倡议。
1. 谁是对的
如果研发人员认为评审后果有问题，评审人员请优先思考开发者是不是对的，毕竟他们“离代码更近”。
如果评审人员认为评审后果是正确的，正当、适当、礼貌的探讨，会让假相更清晰。
研发人员的恶感情绪通常是因为提出问题的形式，而不是对代码品质的保持。
2. 稍后再解决
研发人员最常见的回绝起因，就是进度缓和，心愿可能先做斗争，承诺后续修改。
但通常之后不会再去做这件事，这并非齐全是责任心的问题，而是因为研发人员通常十分忙碌，修复这件事就容易被忘记。
所以最好将评审倡议尽快修复。
3. 评审过于严格
如果评审尺度严格导致研发人员埋怨，那么礼貌的保持十分有必要，严格的代码评审有助于产出优良的代码。
可能过了很长时间后研发人员能力看到这部分代码评审的价值，通过论证后的价值观统一更容易建设彼此的认同感。
总结
代码评审是一项具备长期价值的工作，并且对评审单方都具备价值。不要害怕提出问题，这更容易进步你对问题的认知，如果最终发现你提出的问题是谬误的，这对你也是一项难得的进步。更不要回绝批改问题，即便这些问题在你看来微不足道，重复的正向行为造成惯性，更容易进步工作品质。
参考：
- https://google.github.io/eng-…
作者：康志兴
