本文是“ThoughtWorks敏捷实践关键清单”中的一个关键清单。

代码回顾，又名代码评审、代码检视、代码走查。之所以这样命名，参见旧文Code Review: 超越“审、查、评”的代码回顾。

价值

• 对齐团队约定：通过实例，印象深刻

• 提升代码质量：及时纠偏，又快又好；多双眼睛，多道保障

• 提升人员能力：知识分享，消除瓶颈

集体代码回顾前

1. 氛围安全：领导者能否确保代码回顾所发现的改进点，仅用于过程的持续改进，而不会用于绩效考核？

2. 良好工具体验：领导者能否确保团队获得用户体验良好的代码回顾工具，以便高效进行集体代码回顾？

3. 频繁小批：集体代码回顾主持人是否频繁小批地进行集体代码回顾？如每周3次左右，在固定时间和固定地点，回顾30分钟～1小时，不会超时？

4. 风险排序：集体代码回顾主持人是否按风险程度，将代码提交进行排序，从而对其中风险较高的进行集体回顾，对于风险较低的进行一对一回顾？

5. 沉淀检查单：集体代码回顾主持人是否将以往代码回顾所发现的重要问题和解决方案进行沉淀，形成代码回顾检查单，并分享给所有开发人员？

6. 利用检查单：开发人员能否在编写代码时，利用工具或代码回顾检查单，随时发现代码质量问题，并持续改进？

7. 单意图提交：开发人员是否保证每次的代码提交，都是单意图的，而不会包含多个意图，且将该意图清晰地表述在提交说明中，以提升代码回顾效率？

8. 面向主干：开发人员是否已经解决了要回顾的代码与主干之间的冲突，以便做回顾？

9. 利用工具：开发人员是否在编写代码的过程中，利用sonarlint或intellij的inspect code功能，扫描所修改的代码，识别其中的高风险技术债，并及时修复？

10. 技术债识别与偿还：是否建立定期“技术债代码回顾”机制，频繁小批地识别与偿还sonarqube扫描出的严重的技术债，以及难以用工具扫描出的软件架构和基础设施的严重技术债，作为“新变更代码回顾”的补充？

集体代码回顾中

1. 记录问题：开发人员是否指定人员记录回顾中所发现的问题？

2. 整体质量：开发人员是否以提升代码可理解性、可扩展性、可测试性来进行代码回顾，以保证每次代码提交都能实现功能和非功能性需求，提升软件整体质量？

3. 莫忘测试：开发人员是否回顾自动化测试代码？

4. 基于提交回顾：开发人员是否基于主干上的每次提交，对比新旧版本进行回顾，而不是不加对比直接看整个文件？

5. 优先回顾问题修复：开发人员是否优先回顾了以往代码回顾所发现问题的修复代码？

6. 高风险优先：开发人员是否优先回顾了风险最高的代码提交？

集体代码回顾后

1. 尽快修复：开发人员是否按照记录，尽快修复代码回顾中所发现的重要问题，并以单意图的形式提交到主干？

2. 度量成效：是否度量并沉淀代码回顾成效（如：最近7日“未回顾提交数/提交总数”，最近7日“未修复回顾问题数/已发现回顾问题数”，最近7日代码提交等待回顾平均天数，最近7日代码回顾修复平均天数，最近7日集体代码回顾次数，最近14日代码回顾问题排行榜），以便持续改进？