code review 是每个技术团队都有的一项常规的工作。
code review 总是让人又爱又恨。它很有必要，但是它又很难操作，我们经常陷入审核还是不审核，严格还是不严格来回纠缠中。
以前在一家外企工作，经常是我今天下班前发邮件提交代码审核，第二天上班的时候查看一下审核的结果，然后再提交代码。经常为了在代码审核结果出来前，我能够继续往前推进工作，不得不付出额外的 git 操作。不过这种漫长的 review 过程，也养成自我代码审核的要求，发送审核前都会多次自己检查。
代码审核是一件细致的工作，审核人员必须能够像对待他自己的编程工作一样对待代码审核，代码审核的工作成为审核人员另外一项重要的工作。而实际上，很多团队并没有意识到需要给审核人员单独开辟出来时间。
代码审核工作对审核人员要求还是比较高的，他经常需要付出额外的劳动，还得不到认可，他会一直担心会不会被人吐槽审核太严，没有意义，不会变通。很多时候，只能组长通过行政压力去进行代码审核，而其他人很难，也很不愿意去执行认真严格的审核。管理者确实需要增加一下审核人员的奖励。
代码审核碰见大量代码的时候，就是灾难，每次我们新开发一个业务的时候，会增加大量的代码，这种代码让审核人员不知所措，唯一的办法就是花时间去了解每一个细节。
而对于一些少量的代码修改，审核人员无法正确评估出代码改动引入的风险，唯一的办法，审核人员还需要去阅读更多的代码，了解整个代码的前因后果。
很多时候，代码审核并没有为我们提供有价值的修改意见，也很难达到提升开发人员技术水平的目的，所以开发人员会对代码审核失去动力，仅仅把它当成是一项日常工作而已。
有时候我们的代码审核变成了代码格式的审核了，当我们在代码审核中，如果提出的意见都是代码格式的问题的时候，我们就需要关注一下，我的审核的方向跑偏了。我们更多应该集中在逻辑上，设计上的讨论。细节方面可以由编程规范和自动检查工具来完成。
面对面的代码审核是比较高效的，虽然需要双倍的时间投入，但我们应该坚持这样做。
代码审核对于开发人员还是很重要的，它应该是开发人员技术提升，技能交流的重要手段，如果团队的代码审核流于形式，那么团队的整体能力提升肯定是有问题的。
阅读原文 ： Code Review都有哪些坑 https://www.michaelagreiler.com/code-review-pitfalls-slow-down/
- EOF -
本站文章除注明转载外，均为本站原创或编译。欢迎任何形式的转载，但请务必注明出处，尊重他人劳动。
转载请注明：文章转载自 Binkery 技术博客 [https://binkery.com]
本文标题： 【文章阅读】Code Review都有哪些坑
本文地址： https://binkery.com/archives/2019.09.20-Code-review都有哪些坑.html