Code Review最佳实践

因为最近在工作上参与制定了团队的一些Code Review(CR)的规范，所以想在这里给大家分享一下我们积累的一些CR最佳实践。本篇文章会包括下面这些内容：

• 为什么需要Code Review
• 什么时候做Code Review
• Committer需要注意什么
• Code Reviewer需要看哪方面的内容

为什么需要Code Review

对于参与人数大于或者等于两个的项目来说，CR是一项必不可少的活动。在我看来它有下面这些好处：

可以提高committer对于自己代码的要求

按照我以往的经验来说，有些人的代码在被review和不会被review的时候风格是完全不一样的。如果一个人写的代码不用别人看，永远都是直接推到或者直接合入主分支的话，这个人写代码的时候就不会有什么顾忌，自己想怎么写就怎么写，反正也不会有人看。可是当他的代码需要被同伴review时，他的心态就完全不一样了，这个时候他会想办法精简代码，去掉一些硬编码的逻辑从而追求一些最佳实践，而且各种TODO和FIXME也会写得一清二楚。因为他如果不怎么做的话，作为一个及格的code reviewer，我们是肯定不会将他的代码合入主分支的。长期如此的话，committer的代码水平也会逐渐得到提高的。

组内知识分享

俗话说的好：你有一个苹果，我有一个苹果，我们交换一下，一个人还是只有一个苹果；你有一个思想，我有一个思想，我们交换一下，一人就有了两个思想。这句话同样适用于我们进行软件开发。作为一个程序员，我们在面对同一个问题的时候，可能会有不同的解决方法。如果大家没有交流的话，每个人可能永远都只知道一种解决方法，大家也就没有进步可言。那么程序员之间如何互相学习呢？最简单的办法就是看别人的源代码，而CR就是最好的阅读别人源代码的过程。因为当我们在帮committer进行review的时候，他提交的代码只专注于解决一个问题，这样代码量就不会很大，我们可以更加清晰地学习到他是如何解决某一个问题的。如果committer恰好用了一个很巧妙的我们之前不知道的办法来解决问题的话，我们就可以学习到新的知识了。

保持项目代码风格的一致性

同一个项目里面不同的程序员由于背景不一样(可能来源于不同的项目，来源于不同的公司)，他们解决问题的方法和思路就不一样。作为一个前端程序员我见过在同一个代码仓库里面同时使用了redux-saga和redux-thunk作为异步中间件的。如果作为code reviewer我们不对committer的代码进行约束的话，项目的代码风格就会多极分化，这无疑会增加项目的维护成本以及后面新加入开发者的学习成本。

提前发现代码的问题

一些经验比较少的开发者在写代码的时候可能考虑问题不够全面，导致一些边缘情况(edge case)没有考虑到，这时候如果code reviewer是一个工作经验比较多的同学的话，就可以帮committer提前发现问题，这样就可以避免在产品上线后再浪费时间去定位问题了。值得注意的是，就算code reviewer