如何进行Code review？ 见过很多架构师、高级软件工程师抱怨过Code review没什么效果，这次review出现的错误，下次review时还会出现。也碰到过猿猿抱怨的情况：Code review 浪费时间，很多业务还等着开发呢；或者，Code review那就是某人装X。为什么Code review 那么不好做，没有效果，而且很多公司做不好呢？ 我的观点是，思路比方法重要，Code review  是为了推广代码的最佳实践，而不是挑出代码存在的问题。 读过上篇应该能得出这样的结论——代码审查是要找出程序代码中问题，提高代码质量。那我们是不是code review 就是去挑错?相信很多人的回答是肯定的，因为我见过很多公司就是这么去做的。 如果你仔细读过上篇，应该还会得到一个结论：提高程序员的技术水平！ 挑错只是针对即将投入生产线上的环境的一个战术层面的方法论。让程序员技术水平提高，保持对优秀代码的追求意识，才是确保代码质量的关键和最终目标，属于战略层面。团队技术水平，才是解决代码质量的关键。 按这个思维方式，不仅可以达到确保和提高代码质量的目的，并且在Code  review实施过程中减少猿猿们的抵触心理和心理压力，阻力没有了，才可以取得持续和高效的效果。对此借用George Perkins Marsh 的一句话。 看，是与生俱来的本领；发现，则是一门艺术。——George Perkins Marsh

图片说明 ：《梵高割耳朵自画像》，1888年梵·高邀请高更来阿尔同住，但两个固执的艺术家却是不断的争吵。在一场剧烈争执后，高更大怒而去，梵·高无法阻止，亦无法抑制自己的激动，竟割下自己的右耳。

我最喜欢的梵高画作，因为他对自己认定的东西有着固执的追求的性格。 优秀的代码， 和美的东西东西一样，人打心底是渴望，而不是排斥的。Code review 就是要激发猿猿们对美的（代码）追求。在猿猿们还没有这种意识之前，最好的Code review方式是把尽可能多的人召集起来，如果代码涉及效率、并发、安全等问题，可以邀请相关方面的专家一起review。以上篇提到的代码规范和专家的意见作为衡量标准，在指出问题的同时，将经过优秀的代码即时的扩展到整个团体。同时，建议邀请对代码有洁癖的”固执“者，在辩论中，加深印象、碰出火花。合理有效的利用观点冲突，可以很好地发现问题，解决问题。犹如这幅画作，就是冲突的结果。 当猿猿们有追求优秀代码的自觉，较强软件质量意识培养起来的时候，才可以采用结对编程的方式。特别是互联网行业这两年的膨胀的情况下，团队成员总是处在磨合期的情况，更应执行团体review的方式。把Code  review 做为成员磨合的一个团队建设活动。在追求美代码思想的引导下，避开针对个人，在猿猿之间形成以代码规范为基础的语言体系；不仅可以Code review取得良好效果，而且可以快速融合团队，提高团队工作效率。及时的Code review还可以在代码交付测试前，发现功能遗漏、逻辑缺失，范围蔓延的问题，确保满足需求，不增一分，不减一毫。 何时进行Code review，每周一次还是每周两次？个人认为，最少每周一次，以项目紧张程度，见缝插针。时间紧张的时候，可以将代码审查时间缩短一些，但是一定要维持一定的频率，以时刻提醒，让猿猿们养成最求好代码的习惯。 代码review， 不只可以review项目成员代码。也可以安排阅读学习开源项目优秀的代码，例如Java 源码，Apache 下的项目。通过对它们的阅读，了解什么样的代码才是优秀的，也了解到优秀项目的代码也是会有瑕疵的。这样猿猿们看到别人代码有瑕疵的时候，不会过于代码洁癖，培养猿猿们相互之间的包容心。 激发猿猿们追求美（优秀代码）的意识，是Code review的终极目标。猿猿有了艺术的追求，这没准能帮助他们找对象呢。：）

后面的话：Code review  所有优秀代码，形成的规范，除了形成规范文档外。还可以进一步将规范落实到各种代码检查工具之中。以JAVA为例，关于代码样式：可以将代码样式在check style里定义，并定义成template文件；也可以将代码语法，编译错误检查放到 Find bugs里去；也可以Jeking + 定制sonar 的方式来完成代码的检查。更高级的玩法是代码通过模板来生成，采用DSL来生成代码，这里不展开。其它语言也是大同小异。

---

分享者简介

易荣平，架构师，总体规划成员, 负责国美在线总体架构规划，技术规范制定和技术研发推广。善于分析解决复杂业务需求，提出技术解决方案。了解产品设计、敏捷开发，对技术充满热情，关注电商、互联网、云计算、大数据、人工智能。

个人公众号：荣平

---

                                                        中生代技术群微信公众号