让CodeReview成为一种团队习惯

让CodeReview成为一种团队习惯

The biggestthing that makes Google’s code so good is simple:codereview.That’s not specific to Google – it’s widely recognizedas a good idea, and a lot of people do it. But I’ve never seen another largecompany where it was such a universal. At Google,no code,for any product, forany project, gets checked in until it gets a positive review.

这是一位来自谷歌的同事讲的，希望和大家共勉。

问：1、为什么要进行CodeReview？

答：（1）CodeReview的目的提升代码质量，尽早发现常见、普通的缺陷与BUG降低修复成本，同时促进团队内部知识共享，帮助更多人更好地理解系统；

（2）保证组内人员良好的沟通，使得产品代码更容易维护；

问：2、在什么时间进行CodeReview？

答：在每次代码CheckIn之前进行；

问：3、进行CodeReview应该遵循哪些基本规则？

答：（1）需要对CodeReview形成一致的认识，如果在对该事物的认识上存在分歧，那么会增加CodeReview工作的难度；

   （2）需要对基本的编码规范形成一致性的认知，即形成同一个代码规范；

   （3）CodeReview必须在代码CheckIn之前完成；

   （4）CodeReview应从设计到编码逻辑进行细致的review，故需要参与成员的紧密沟通合作；

   （5）必须准确记录CodeReview过程中发现的问题，可以使用问题点记录单；

   （6）Review过程中可以要求作者讲解，遇到不清楚的逻辑点要处分提问讨论；

   （7）要形成讨论问题、解决问题的气氛，不能把CodeReview搞成批判大会；

   （8）Code的作者应对Code质量负责；

   （9）引导轻量Review：如果一次性Reviewissue过多，会严重影响Review的质量；

问：4、如何算一个合格的CodeReviewer？

答：（1）要有一颗挑刺的心；

   （2）要有一颗包容的心；

   （3）要有一颗好奇的心；

   对于Reviewer来说，最大的收获不是找到了多少bug，而是在Review过程中大家学到了什么[一万个读者眼里就有一万个哈姆雷特]就是这个道理；

问：5、项目这么紧是否可以把CodeReview放到以后再进行？

答：不行，如果不在前期进行把控，不进行必要测检查，我们的代码就会变成没有规划的高速公路，到时候你自己也找不到哪条才是正确的；

问：6、通过CodeReview我们到底能得到什么？应该的到什么？

答：CodeReview最大的优点是社交性质的。如果你正在写代码，并且你知道你的同事将会要查看你的代码，那么你编写的时候就会更加的慎重和仔细。你的代码会更加的整洁，注释更加完善，并且更有组织性。因为你知道一个人将要查看你的代码，并且你对他给你的代码的评价很关心；

CodeReview的一个更大的好处是，它可以传播知识（就是同事之间可以分享技术和编程方法）。在许许多多的开发小组里面，每个人都是负责自己的一个核心模块，并且每个人基本上都把主要的精力放在关注自己的模块上面。只要同事的模块没有破坏自己的代码，基本上是不会看别人的代码的。带来的一个（不好的）影响就是，对于某个模块可能只有一个人熟悉它的代码。如果这个人休假了或者——天晓得——离开了公司，（在短时间内）就无人知道这个模块的任何内部细节了。

那么我们能得到和应该得到的就很清晰了：“达摩克利斯之剑”“知识分享”。

 

最后，希望我们可以真正做到：

No code,forany product, for any project, gets checked in until it gets a positive review。