我想没有人否认code review（代码评审、复查） 对提高代码质量的作用，如何进行code review？ 这里确实存在一些方法和技巧以及理解和认识。方法不当，会浪费大量时间、造成低效率；流程过紧，会大大降低生产力，怨声一片，流程过松，理解轻视走过场，很难知道code review的效果，甚至有没有进行code review，都很难判断。

　　代码评审在我们公司项目组内对大多数人来说都是痛苦的经历。尤其是开发人员，开发人员通常感觉做的都是无用功，而且根本不重视或理解，认为根本就是没有无用之功，过程所迫之举。就形成了代码评审无效而痛苦，过程存在而效果皆无，回头又叹息之怪圈。

　　那就让我们来一起好好的回顾一下吧。

　　代码评审，我们先来说说它的目的，我想很多人都能说得头头是道比咱都好，不过咱再说一遍，希望各位再温习一下，代码评审我认为就两个目的：

　　第一，确保要发布质量可靠的代码。通俗点就是，它对于开发过程中的下个阶段是否应该提高代码的质量，是个严峻的考验。代码评审能非常有效地发现所有类型的错误【注：有代码规范标准】，包括那些由于不正确的结构引起的错误，那些不适合需求的错误，还有那些简单的冗余错误。这就是为什么它对于代码质量来说是个有效的试金石【再大的目标我们在下面说吧】。

　　第二，作为新近人员的工具，帮助学会何时并且如何应用技术来提高代码的质量、一致性和维护性，掌握业务与技术之间的关系。经过反复仔细地评估代码，开发人员有机会掌握不同的和潜在的更好的编码方法。

　　下面在说说我们的老大难，无效而痛苦的代码评审，代码评审常常以错误的方式开始，因为开发人员感觉它是个多余的措施，被强迫接受；或者在时间紧任务重人员少的某些情况下开始。这两种观点都是不正确的。代码评审被证实是最小化缺陷的有效方法。无论公司实行代码评审的额外动机是什么，代码评审都是行业化的最优方法。

　　在代码评审过程中，我们听到最多的就是，代码没有什么问题；别评审了，浪费时间，直接单测不就行了；还有诸如，我们评审了，符合缺陷密度【后面小声的说都是凑数出来的】......

　　这说明什么，首先而且明显的就是大家没有从代码评审的过程中得到好处，再有就是总想着在下一个阶段发现问题一起来修改，而且认为浪费时间，再不就是为了规定片面的走过场凑缺陷密度，认为代码评审是无效而且痛苦的过程。

　　呵呵，既然这个步骤不能省略，那为什么我们就不能让它变成有效而不痛苦的代码评审呢？