Code Review 代码审核最佳实践

Code Review，中文叫代码审查，指的是完成了部分功能的代码开发之后，在代码真正合并到仓库主分支之前，邀请同事帮你进行代码的审核和检查，检查代码的质量、规范、设计等等方面的过程。

进行代码审查的好处很多，其中一个就是可以让团队的整体水平快速得到提升。一个团队中有资深的工程师也有刚毕业的人，水平参差不齐。对于刚进入团队的人来说，不熟悉很多团队的规范，那么就可以通过代码审核的过程进行指导和分享。

如果系统之间非常复杂，互相之间的依赖调用很多，一次代码的修改可能会影响其他系统的运行，这时候，如果有比较熟悉这个系统的人的提醒和指导就可以及时发现问题，新人可以在这个过程中学到系统设计的原则，如何编写可读性和复用性强的代码，学习到系统工程最佳实践等等。团队的水平因此而得以提升。

对于团队中的资深人士来说，他们可能觉得帮助新人会浪费自己的时间，其实不然。当整个团队更加优秀，水平更高，就可以帮忙分担更多重要的任务，而自己也可以抽身去解决更难的问题或者进行自我提升。

团队的沟通能力越强、设计能力越好其实也是节省了自己的时间。谁不希望可以高效地和别人合作完成任务呢？与其低水平地交流合作，事情还迟迟完成不了，不如投入一些时间提高团队的战斗力。

许多公司团队不注重代码质量，认为工作完成了，功能上线了就可以了。其实大家没有看到软件的生命周期中，成本最重的一个环节就是持续的维护和更新迭代。

代码质量差，是将来欠下的技术债。代码随心所欲地写，每个人有每个人的喜好，没有任何规范，也不注重可读性。虽然系统表面上解决了当下的问题，但是当团队成员流动，新人接手项目后，发现读不懂，代码如“屎”山，项目推翻重做，之前的投入付诸东流。这个用人成本是否有考虑过？

举个简单的例子，就像建造一个楼房，为了赶工期不注重工程质量，房子外形是符合交付标准了，但是房子内部的东西偷工减料，楼房的使用寿命没过多久就变成危楼，无法使用了，造成了大量的人力和资源的浪费。

开源软件对代码的审核非常严格，这也是为什么开源软件的质量那么高以及能够经久不衰。开源项目的委员会会非常严格地审核每一行代码。良好的设计和优秀的代码质量才得以让开源软件保持稳定的迭代，以及持久的生命力。

代码审查有诸多的好处，而它的目的就是要引入团队协作规范，让所有贡献代码的人都能够按照一定的流程和约定来完成开发任务。

许多公司的代码审查流于形式，只是走个过场，虽然需要别人同意才能够把代码合并进主分支，但是没有人对代码进行严格的考核，代码风格也没有统一的约束。

有些人对代码审查比较反感，认为是一种拖慢进度的强制流程。然而据我观察，对于那些能够真正运用好代码审查的公司，这对员工来说是一种福音，更像是大家共同建设的一种工程师文化。因为对于个人而言，可以快速地学习和提升，对于公司而言，软件的质量得到了保证，是一种双赢的举措。

良好的代码审查，少不了人和人之间建立起的良好氛围，如谦逊，友善，互信互助和成长型心态。

作为审核别人代码的人，需要就事论事，评论的语气要尊重他人，客观公正，带着帮助别人的心态去完成审核。不要带有主观色彩，也不要有针对个人的行为。

作为提交代码的人，不要害怕被别人发现自己的短板，不要对自己做的不好的地方遮遮掩掩。带着成长型的心态，发现问题就去解决，不会的东西就去学，虚心请教和学习，收起玻璃心，一切以成长为目的。一旦团队建立起良好的学习氛围，代码审核的机制会朝着正循环滚动。

讲述了以上诸多的背景，来到正题，在国外大厂里，code review到底是怎么做的呢？

有些人提交code review，什么也不说，就一段代码给到审核的人，以为别人什么都知道，应该知道他要实现的功能和达到的目的。

其实作为提交者，应该站在对方的角度思考，假设对方对自己的实施过程一点都不了解，应该怎么提供更加详细的信息。

以上的目的，都是为了让对方更好理解自己的目的，详细的文档也为了以后再翻阅提供便利。

一旦有人评论了你的代码，应该尽快回复并解决，拖得越久，代码审核的成本越高
- 一方面，在你审核的过程中，会有新的代码合并到主分支，会导致你需要不断地同步自己的代码，解决代码冲突，造成时间的浪费
- 另一方面，时间长了，又要去回忆当时的一些讨论，会导致代码迟迟无法合并
已经解决的问题，可以点击”Resolve“，让整个review的过程更加清晰，也知道自己的代码进度如何