大家好，我是大头，职高毕业，现在大厂资深开发，前上市公司架构师，管理过10人团队！
我将持续分享成体系的知识以及我自身的转码经验、面试经验、架构技术分享、AI技术分享等！
愿景是带领更多人完成破局、打破信息差！我自身知道走到现在是如何艰难，因此让以后的人少走弯路！
无论你是统本CS专业出身、专科出身、还是我和一样职高毕业等。都可以跟着我学习，一起成长！一起涨工资挣钱！
关注我一起挣大钱！文末有惊喜哦！
关注我发送“MySQL知识图谱”领取完整的MySQL学习路线。
发送“电子书”即可领取价值上千的电子书资源。
发送“大厂内推”即可获取京东、美团等大厂内推信息，祝你获得高薪职位。
发送“AI”即可领取AI学习资料。
大厂中的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的呢？可以发出来大家一起聊聊。
文末福利
关注我发送“MySQL知识图谱”领取完整的MySQL学习路线。
发送“电子书”即可领取价值上千的电子书资源。
发送“大厂内推”即可获取京东、美团等大厂内推信息，祝你获得高薪职位。
发送“AI”即可领取AI学习资料。
部分电子书如图所示。
