两个 code review 案例
先分享我参与某团队代码评审的案例
我曾经被某个团队邀请参加代码评审，要评审的业务我没有参与，也不了解；邀请来的也很突然，一个同事走到我工位旁，说 xx 会议室有个 code review， 你也参加一下吧，就这样跟着同事到了会议室，投影里直接就是用 eclipse 打开的代码
人到齐后，开发人员就开始讲代码了
前半程我是懵逼的，只能听其他参与评审的同事发问，听着听着我品味出来了，大部分参与的人都是懵逼的，保持沉默；有一个比较活跃的同事，问的问题也基本不涉及业务——比如，他的问题是调用远程接口时如果失败，有无重试机制，是怎样的重试机制
后来我听明白业务了，这是一个订单支付回调的业务，第三方支付在用户完成支付以后，回调我方的通知接口，我方再执行订单状态修改、发货等后续业务——能搞明白的主要原因是我以前做过类似的开发，所以我也发现了问题：在第三方支付回调我方通知接口时，我方的接口可能会返回失败，这样可能导致死循环——我的建议是先返回成功，订单状态修改和发货等操作异步处理
再分享一个我的代码被评审的案例
我曾经在上级主管要求下组织过一次代码评审，由于业务比较复杂，参与的人基本没有在业务逻辑上提出什么意见和建议，倒是有个同事提了个关于缓存的问题，当时把我搞懵逼了
出于性能考虑，我的程序里把数据库里的对象全部加载到本地缓存，用 map 来存储，这个同事的问题是：如果有人修改了 map 里缓存的对象怎么办？
我回答，我的 map 用到了 google 的 Guava 库里的不可变 map，这个答案明显是答非所问的，因为当时我完全没有考虑过被缓存对象自身被修改的问题，一时之间没有正确理解他的问题
他的这个问题对我有很大的启发，后来我解决了他提出的问题：被缓存的对象应该做到不可变，即该对象只有 get 方法，不能有 set 方法，对象的所有属性都用 final 修饰
问题
我参与过的大多数代码评审，实际上都有些共性的问题
- 代码评审几乎都是应领导要求而开展的，组织者邀请的评审人员，基本是本部门或者跨部门团队的一些高级开发人员
- 组织是无序的，好一点的能提前一天通知；不好的就是临时通知，立马参加，完全没有准备的时间
- 就算是提前通知的，很少能提供要评审代码的原始需求、设计等相关文档；即便提供了，真正认真看过的人也是极少的，这导致了要评审的代码，其业务逻辑对于多数的参与者是未知的，参与者在前半程基本是懵圈的状态，往往只能就业务逻辑以外的编码规范、系统架构、某些中间件的使用上进行评审
- 多数的参与者是在打酱油，整场评审下来要么一言不发，要么敷衍的问几个无关紧要的问题，对他们来说参与代码评审就是浪费时间
- 参与者付出了时间，却没有任何收获
- 缺少反馈，评审过程中提出的问题有没有解决，建议有没有采纳，谁也不知道
我的看法
代码评审有没有用？当然是有用的，比如我就在代码评审里发现了自己开发中的一个盲点
但是，前述代码评审的做法是存在优化空间的，一次有组织的代码评审，至少邀请 5 个以上的高级开发人员，其中大部分人大部分时间在打酱油，这是不是人力上的一种浪费？
另外，是否考虑过初、中级的开发人员，还有测试同学，也是可以且有必要参与代码评审的？
代码评审不仅仅是评审某一段具体的代码——程序员职业生涯里要写的代码太多，不可能做到每段代码都被评审，如果想靠代码评审保证软件质量是不现实的
代码评审应该是软件过程里的一个链条，要和其他过程串起来，比如设计、测试等，从而保证软件开发质量
就比如说测试吧，测试同学参加代码评审，有助于了解业务逻辑的实现，更有利于他们进行测试用例的设计
代码评审要让所有人都参与进来，除了被评审的同学，评委是否也能从代码评审里学习到什么呢？比如说，设计缺陷或者程序 bug，很多时候是具有共性的，在评审中指出后，也可以警醒其他开发人员比如说在座的评委。
所以我觉得中级或者初级开发人员、测试同学也应该参与到代码评审中来，而参与并不一定是要指出问题，提出建议——单纯的依据标准进行评价也是一种参与
最后，代码评审结果要有反馈，问题是否解决、建议是否落实，应该要有人负责
我的实践
- 代码评审是例行的，每周进行
- 参与的人员，除了相关的开发人员，还包括测试人员
- 代码评审不能从代码开始讲起，要从需求、设计开始
- 评审哪些维度，标准是什么？需要明确
- 评审要有反馈
最后，给出我的团队实行过的代码评审制度供参考
xxx 团队代码评审制度
概述
为了规范编码过程，保障代码质量，提升开发技能，服务端开发组将开展例行的代码评审活动
制度
若无特殊情况，代码评审作为一项例行的工作每周进行
时间
每周 4 晚 19:00~21:00
参与人员
- 主讲
- 服务端开发组成员，以周为单位轮流担任，顺序为[刘备-关羽-张飞-赵云]
- 特殊情况组长可以调整顺序
- 评委：
- 服务端开发组其他人员
- 主讲、评委邀请的其他部门或小组的同学
- 观察
- 部门内任何感兴趣的人士（主要是测试同学）
角色说明
- 主讲
- 评审的组织者和召集者，包括预定会议室，发送会议邀请，汇总评价，输出评审报告等
- 代码的编写或维护人员
- 提供要评审的代码及其设计
- 进行必要的业务背景、设计思路、代码实现的讲解
- 回答评委的问题、质疑
- 评委
- 评审：指出代码里不符合开发规范、未贯彻设计思路、有错误、理解困难的代码，要求主讲进行解释
- 打分：对本次评审做出量化的评价
- 观察
- 观察和评委的区别是不用打分
评审流程
主题选择
主讲需准备 3 个主题，由评委随机抽取一个作为本次评审的主题。主题可以是
- 一个客户端接口
- 一个 task
- 一个 mq 消息的消费者
- 运营后台的某个操作
- 公共组件
背景知识
主讲介绍本次评审主题相关的业务需求及设计，设计以流程图或序列图的方式展现
代码评审
主讲开始讲解代码，评委可以随时提问
评价
代码评审完成，主讲收集各评委的评分并汇总
总结报告
完成代码评审后输出总结报告，第二天下班前通过邮件发送给所有评委和观察：收件人为所有评委，抄送所有观察，邮件标题为“xxx服务端代码评审报告”，报告格式如下
评分
评分包含 2 个部分，如下
- 规范分，0 – 10 分
- 难度分，0 – 3 分
评审开始后，主讲打印如下表格发给每个评委，并在评审结束后从评委回收评分表
