太长不读版
每日团队代码回顾的宗旨，是改变规则，而非个人。代码质量差，与其追究写代码的程序员的责任，不如建立团队的代码质量保证规则，并持续改善。我们无法改变一个人，让他更具有责任心，因为人只能靠自己去改变。但我们能相对容易地改变团队的规则，去影响人。规则比人更有确定性，且更容易改进。
未经删节版
本文假设
- 团队的程序员都很忙
- 团队线上事故频发
- 团队有新人参与编写生产代码
每日团队代码回顾的定义
“团队代码回顾”，不是由一位有经验的程序员独自去评审另一位程序员的代码的“两人代码回顾”。
而是每天30分钟的团队针对当天所写代码的改进：每天在规定的时间（最好在快下班前）和规定的地点，团队所有程序员用30分钟左右，回顾当天所写的代码，找出其中的改进点，并将改进在下一次代码回顾前落地[1]。
- 为什么要做团队代码回顾，而不是“两人代码回顾”？ 全局观：对于业务复杂的代码逻辑，多位熟悉各自业务领域的程序员在一起看，才能发现其中隐藏的代码缺陷（感谢网友Vernon的反馈） 反脆弱：将知识在团队内传播开，避免团队内唯一懂某一模块的程序员休假，而让团队掉链子 培养新人
- 为什么要每日做？ “10行代码 == 10个问题”， “500行代码” == “看起来不错”， 你还想每周只做1次团队代码回顾吗？
- 为什么每天要在规定的时间和规定的地点做？ 实践证明，对于刚刚实践代码回顾的团队，如果不进行“双规”，那么代码回顾的时间，会被各种突发情况所占用，导致最终没有时间进行代码回顾。
- 在程序员尚未达到全栈水平时，是否需要分别进行前、后端的代码回顾（感谢朋友廖源源子哥的反馈）？ 可以分别进行，但建议不要同时进行，因为这样可以为愿意成为全栈的程序员提供分别参加两次代码回顾的便利。
- 为什么code review不叫“代码评审”，而叫“代码回顾”？ 因为要让“代码回顾”这个名字更尊重人。 要用能给人带来正面感受的词汇指代“代码回顾”： 代码回顾 代码展示 代码改进 代码改善 代码分享 代码复盘（感谢网友张亮的反馈） 而不要使用给人带来负面感受的词汇： 代码走查 代码评审 代码检视（感谢乔梁乔帮主的反馈） 代码审查 代码检查
每日团队代码回顾对团队的价值
能减少线上事故的几率，让团队业务经理能获得更多业绩，并减少通报批评的几率。
能减少计划外的返工时间，让程序员能获得更多的睡眠时间。
修复因忽视团队代码回顾而导致的线上事故，会大大增加计划外工作时间。
程序员的迭代估算，一般不会包括花在修复线上事故的时间。
计划外的返工修复线上事故的时间，只能压榨程序员已经少得可怜的睡眠时间，和思考“重要但不紧急”的事情的时间。
每日团队代码回顾的宗旨[2]
改变规则，而非个人。
代码质量差，与其追究写代码的程序员的责任，不如建立团队的代码质量保证规则，并持续改善。
我们无法改变一个人，让他更具有责任心，因为人只能靠自己去改变。
但我们能相对容易地改变团队的规则，去影响人。
规则比人更有确定性，且更容易改进。
给忙碌者的每日团队代码回顾建议
对于“太忙没时间”的团队
如果团队忙到每天挤不出30分钟一起做代码回顾，其实就意味着团队认为代码回顾的优先级较低。
部门技术领导可以选出两个团队做试验，用数据说话（感谢同事梅雪松梅老板的反馈）。
选出两个团队，团队甲基本不做团队代码回顾，团队乙每日下班前做30分钟团队代码回顾。
搜集并对比两个团队的以下数据：整个团队（包括开发和测试人员）每个月花在计划外返工修复线上事故的时间总和。
让团队乙给团队甲分享每个月在代码回顾中所发现的代码缺陷及所避免的计划外修复时间的估算。
对于有时间做每日团队代码回顾的团队
如果团队每天能在下班前30分钟一起做代码回顾，其实就表明团队认为代码回顾的优先级较高。
入门实践
- 团队通过讨论形成自己的代码规范标准，并通过每日团队代码回顾进行落地和改进（感谢有赞科技杨勇的反馈）
- 让团队所有程序员掌握基本的版本控制工具的技能（感谢同事王晓峰的反馈）
- 利用SonarQube等代码质量扫描工具，事先扫描要回顾的代码，并在代码回顾时展示扫描报告
- 最好在一个有大屏幕电视的会议室进行代码回顾（感谢同事封小武的反馈）
- 业务背景：由代码作者简要介绍回顾代码的业务背景（感谢同事封小武的反馈）
- 可读性：由非代码作者讲述代码变更的意图，看看代码是否具备高可读性。
- 记录并分享：每天都有一位志愿者记录所发现的改进点（日期、模块名、文件名、改进点、改进人），并上传团队wiki系统分享。
- 每次回顾代码前，首先检查上次代码回顾所记录的改进点是否已经修复。
- 统计：统计代码回顾的价值并随时通过wiki分享给团队。 可以统计每次团队代码回顾所能减少的线上事故个数，统计每次团队代码回顾所能减少的开发和测试人员的返工时间（估值）。
进阶实践
- 拥有好用的代码对比工具，比如git和IntelliJ。
- 代码回顾前要问3个问题：
- 回顾的代码是否来自团队主干分支？如果否，那么在把代码合并到团队主干分支后，再来做代码回顾。
- 回顾代码是否搞挂了团队主干分支的部署流水线？一旦搞挂流水线，要么在10分钟内修复，要么回退提交。
- 部署流水线上的用户旅程自动化回归单元测试是否运行成功？如果否，那么先回去把失败的自动化回归测试修复，再来做代码回顾。
- 单意图提交：每位程序员确保每次代码提交都只包含一个意图（感谢同事王晓峰的反馈），这样能避免“‘500行代码’ == ‘看起来不错’”的问题。另外，单意图提交的代码，在阅读、合并和回滚代码时，都会更加容易操作（感谢网友Vernon的反馈）。
- 频繁地合并代码：每位程序员每天至少合并一次代码到团队主分支。这样小批量发现的问题，能更容易解决；能避免“代码合并地狱”；有助于进行代码重构。
- 清晰的代码提交注释：每位程序员确保每次代码提交都在提交注释里面写清修改意图，便于读代码。
高阶实践
- 团队具备把大故事拆成小故事的技能（感谢同事王晓峰的反馈）。
总结
每日团队代码回顾，能让团队用更全面的视角，发现更多的代码缺陷，并且通过每天小批量地修复，让问题更容易解决。从而让团队业务经理能获得更多绩效，减少线上事故通报的几率。并能减少程序员的计划外返工时间，从而获得更多睡眠时间。每日团队代码回顾的宗旨，是改变规则，而非个人。对于“太忙没时间”的团队，可以尝试做试验用数据说话的方法，提高每日团队代码回顾的优先级。而对于能实践每日团队代码回顾的团队，可以逐步采取入门、进阶和高阶实践。
- 感谢朋友廖源源子哥的反馈。 ↩
- 感谢朋友刘晓光的反馈。 ↩
