大厂中的Code Review

周末没事的时候，出来和朋友喝酒撸串，谈论国(chui)家(chui)大(niu)事(bi)。

喝到尽兴的时候，免不了一顿八卦盛宴。男人嘛，聚在一起吹牛逼的时候，无非就是江山美人这些事。

从中华上下五千年聊到他们公司新来了美女实习生。

到这里，我已经脑补出来了下文，比如“领导强迫美女实习生”或是“我和美女不得不说的故事”这种狗血剧情。

朋友A说这个美女是挺漂亮，就是技术能力不太行。改代码的时候，误删除了一行代码，导致线上出现问题了。

这时候，朋友B估计也是喝上头了，开始为美女打抱不平了。

朋友B说，人家实习生，你们也不能要求太多吧，你们公司不要让她来我们公司好了。

好小子，算盘珠子都崩我脸上了。。。

我也奇怪的问了一句，你们厂没有代码Review吗？按理说，这种问题不应该发生吧。

朋友A说，有是有，可能大家都不太认真吧，谁都没发现这个问题。。。也就稀里糊涂的上线了。。。

这个问题，还是过了一个月才发现的。。。

朋友A继续吐糟。这代码Review啊，也不是个什么好活，感觉大家都不太乐意干。主要是

• 增加了工作量
• 出事了还要担责

比如这次，对于这两位代码Review的同事，肯定要被追问，为啥当时没有发现。

说实话，大部分人做代码Review的时候都不做不到很认真。这是没办法的事，毕竟你又要去了解需求逻辑，还要一行行代码的去过。那没几个小时是过不完的，同时你还要干自己的工作。哪有那么多时间去认真Review呢。

所以大部分人应该也就是粗略看一下，没啥问题就给过了。

朋友A也说，他们这次痛定思痛。决定优化代码Review的流程。

优化后的代码Review

角色定义如下：

• 提交人：代码Review的发起人。写代码的人。
• 审查人：负责进行代码Review工作的人。需要对代码进行Review。

对于提交人来说，需要提前拉会进行CR会议，正常需求来说至少提前1天拉会。并明确以下几点：

• 需求文档
• 技术方案
• 代码CR地址
• 主要修改逻辑点
• 自测报告
• 上线时间

这些要求可以帮助审查人快速了解自己需要做什么，重点放在哪里，避免浪费审查人的时间。

当然了这样做确实会增加一些提交人的工作量。但是还算好的。

毕竟，需求文档、技术方案、自测报告都是现成的。也就是写一下主要修改逻辑点而已。

对于提交人来说，还需要选择合适的审查人，至少有一个审查人是了解需求的。

对于审查人来说，同样有一些要求，主要为了让审查人能够认真的对待这件事情。

• 代码逻辑是否正确（需要了解需求）
• 并发处理是否正确
• 单元测试是否覆盖了核心逻辑
• 代码命名、格式、注释。是否能让人一下子就明白这个代码是干啥的。
• 方法抽象是否合理
• 异常处理
• 性能问题
• 安全问题

至少需要检查以上几点，如果有问题及时提出来，让提交人进行解决。

FAQ

Q:如果审查人没有时间怎么办？
A:审查人需要及时回复提交人，方便提交人选择新的审查人。

Q:如果审查人意见不一致怎么办？
A:建议选择奇数个审查人，少数服从多数。

Q:审查人是否会对技术方案提出问题？
A:审查人应该聚焦于技术实现，技术方案的问题应该在技术方案评审上提出而不是代码Review上提出。

Q:紧急需求没时间代码Review了怎么办？
A:紧急需求紧急处理，快速找人Review一下即可。

总结

对于所有人来说，代码Review好像都是一个巨大的问题，很多公司甚至难以推动执行。

我觉得根本的问题在于，代码Review的收益是一个长期的、利他的收益。对于大家来讲，最直观的就是工作量的增加，如果出问题了还要担责任。

大家的公司都是怎么做代码Review的呢？可以发出来大家一起聊聊。