代码评审

我想没有人否认code review（代码评审、复查） 对提高代码质量的作用，如何进行code review? 这里确实存在一些方法和技巧以及理解和认识。方法不当，会浪费大量时间、造成低效率；流程过紧，会大大降低生产力，怨声一片，流程过松，理解轻视走过场，很难知道code review的效果，甚至有没有进行code review,都很难判断。
    代码评审在我们公司项目组内对大多数人来说都是痛苦的经历。尤其是开发人员，开发人员通常感觉做的都是无用功，而且根本不重视或理解，认为根本就是没有无用之功，过程所迫之举。就形成了代码评审无效而痛苦，过程存在而效果皆无，回头又叹息之怪圈。
    那就让我们来一起好好的回顾一下吧，
    代码评审，我们先来说说它的目的，我想很多人都能说得头头是道比咱都好，不过咱再说一遍，希望各位再温习一下，代码评审我认为就两个目的
    第一：确保要发布质量可靠的代码，通俗点就是，它对于开发过程中的下个阶段是否应该提高代码的质量，是个严峻的考验。代码评审能非常有效地发现所有类型的错误【注：有代码规范标准】，包括那些由于不正确的结构引起的错误，那些不适合需求的错误，还有那些简单的冗余错误。这就是为什么它对于代码质量来说是个有效的试金石【再大的目标我们在下面说吧】。
    第二个目的是作为新近人员的工具，帮助学会何时并且如何应用技术来提高代码的质量、一致性和维护性，掌握业务与技术之间的关系。经过反复仔细地评估代码，开发人员有机会掌握不同的和潜在的更好的编码方法。
    下面在说说我们的老大难，无效而痛苦的代码评审，代码评审常常以错误的方式开始，因为开发人员感觉它是个多余的措施，被强迫接受；或者在时间紧任务重人员少的某些情况下开始。这两种观点都是不正确的。代码评审被证实是最小化缺陷的有效方法。无论公司实行代码评审的额外动机是什么，代码评审都是行业化的最优方法。
    在代码评审过程中，我们听到最多的就是，代码没有什么问题；别评审了，浪费时间，直接单测不就行了；还有诸如，我们评审了，符合缺陷密度【后面小声的说都是凑数出来的】……..
    这说明什么，首先而且明显的就是大家没有从代码评审的过程中得到好处，再有就是总想着在下一个阶段发现问题一起来修改，而且认为浪费时间，再不就是为了规定片面的走过场凑缺陷密度，认为代码评审是无效而且痛苦的过程。
    呵呵，既然这个步骤不能省略，那为什么我们就不能让它变成有效而不痛苦的代码评审呢？
    最后回过头来，让咱再说说如何成为有效无痛苦的代码评审，以及能够得到显而易见的好处。
    代码评审，不打无准备的仗，要有一定的高度
    高度一：制定编码规范，预防＂差不多先生＂；
    高度二：代码讲究简单实用，效率高，忌讳简单复杂话；
    高度三：代码评审让我们能够观览众山，领略无限的风光；代码评审让我们能够站在巨人的肩上，看得更远。
    对于目前公司的评审，代码评审需要改进如下几个地方：
    首先，在评审的代码的量上应该把握一个度。
    其次，应该有一个评审的核对表，最后提供预审汇总表单，问题及时审核确认。
    最后，评审会议应该在参与人员充分准备的情况下召开。
    很好的执行评审，咱就能够得到好处了：
    第一：代码评审会尽可能的将Bug杀死在萌芽阶段，先期发现Bug的成本要远远小于后期发现Bug的成本，越早发现代码中的问题对整个系统的控制和把握就越有利；
    第二：代码评审过程是一个知识技能传承与互补过程，有利于新人成长，而且效果奇佳；
    第三：代码评审会让你加深对业务的理解。
    最后来个结论吧，
    代码评审经常被误用或理解有偏差，而且对于开发人员来说是痛苦的，但是又不得不评审。使用些简单的措施或行之有效的方法可以使痛苦的经历变成学习的过程，并且能够改善代码质量，提高工作效率，这样你开心我开心，大家都开心，而且项目进展顺利，何乐而不为呢。 
    最后来句口号吧，让我们要把代码评审进行到底