为什么要Code Review

Code Review是我们项目成功的最有力的武器。下面我先谈下我理解并实施的Code Review.

1. Code review的层次。

最基础的，也是所有人都会想到到的，就是编码规范，类，方法命名什么的，还有代码格式...这些是程序员的基本功底，默认选项；多年前领导要我搞个编码规范，我说大家都熟知的规范就已经很好了啊；当然公司内部也需要这方面的规范，比如项目如何命名，包如何命名等这些。

更高一层次的，也是说的比较少的，是代码的质量。前面能保证代码写的好看，大家看了都还顺眼，但并不能保证代码的可工作性，合理性，健壮性，可维护性。我们需要可以解决问题的代码；我们需要最合理(最是相对的)的代码；我们不希望破坏现有的架构搞特殊处理，如果架构本身不适应，那就可控制的重构；我们不希望有个工作很好的功能被破坏。

2.Code Review的好处

第一，最少有两个人对同一段代码深刻理解，并且认同。如果不能做到敏捷要求的“结对编程”的味道，我们就打个折执行吧。这一点从公司正常运营上，也是有好处的。

第二，开发人员可以放心的把自己的创造性发挥出来，因为他知道他有个坚强的后盾，绝不会等到QA发现不可饶恕的错误，然后经理过来骂你一顿。

第三，开发人员都会尽全力写最好的代码；软件开发人员都是要"face"的，不想当时就被别人找到缺陷，尤其是你身边的同事。再也不会只顾今天，不管明天会怎样；对软件的可维护性更加尽心。

第四，极大的提高软件质量，以及可维护性。当然这要求Review人员的责任心，以及专业精神。如果是维护性项目，经验也是相当重要的。

3. Code Review的重要性

至此，其重要性以已经不言而喻了。个人认为某种程度上其重要性以及你改超过Unit Test.

4. Code Review不好实施的原因

Code Review如此重要，但是据我接触的人跟公司来看，真正认真执行的并不多。其原因无非：

ü 项目时间紧，时间跟人员都不充足；如果是这种情况，建议招点人，项目计划制定的更合理些。

ü 重视程度不够；开发人员都觉得自己很牛，代码不需要给别人Review。其实问题往往就是由于过分的自信造成的，需要公司高层多做宣导，并形成制度，强力执行。等过一段时间，大家都会体验到其中的好处的。

ü 执行起来比较麻烦。这是大问题。如果你让开发人员觉得做Code Review是件很容易的事，并且收益大于付出，大家就愿意做了。我们Team大致经历过三个阶段。

第一阶段，按制定的流程，开发人员把修改的代码用邮件发给Review者，并说明改了什么，对系统那些功能有影响。然后负责Review的人Copy到Eclipse，对比CVS, 看代码的改动是否合理。然后再邮件通知合格，或不合格，并说明原因(口头或书面)。

第二阶段，开发人员都觉得这样太繁琐，费事费力；于是我们开发了个Eclipse插件，帮助开发人员对自动生成代码改动细节的邮件，并把改动的代码自动放到指定的公用文件夹中。如此一来开发人员生成一个Code Review的请求，就是分分钟的事情了(右键，写点什么，完成)就好了。

第三阶段，开发人员现在很Happy了，但是Review的人觉得还是有点麻烦，要Copy,要写邮件。于是我们把插件又改进了下，Review的人也可以在Eclipse上一键把代码copy进来；然后提供了一个Web Console供头头看我们Code Review的情况。

code review 怎么使用

如何用 Gitlab 做团队内的 Code Review

不少开发团队和创业公司都在纠结是否要执行 code review，既希望改进代码质量，又担心带来的负担会拖慢项目进度。实时上，在软件开发中质量和效率往往并不是二选其一的关系。能产出高质量代码的团队通常效率也非常高。

作为工程师的职业经历中，自动化测试和 code review 可说是能同时提高代码质量和开发效率的两个最有效的手段。所谓 code review，和学术界的 peer review 类似。Peer review 是由同事或同行对一位作者的作品进行查阅并提出建议和问题，只有当所有提出的问题都得到满意的答案后，作品才能发表。对于 code review 来说，作品就是代码，发表就是把代码 commit 到官方代码库。代码评审是指在软件开发过程中，通过对源代码进行系统性检查的过程。通常的目的是查找系统缺陷，保证软件总体质量和提高开发者自身水平。 code review是轻量级代码评审，相对于正式代码评审，轻量级代码评审所需要的各种成本要明显低的多，如果流程正确，它可以起到更加积极的效果。正因如此，轻量级代码评审经常性得被引入到软件开发过程中。 其实要编写起来很简单 写一个文档. 把以下内容完成叙述出来即可. 1、最近一次迭代开发的代码 2、系统关键模块 3、业务较复杂的模块 4、缺陷率较高的模块 注意: 代码评审不是批斗会，不能以缺陷和错误来打击开发人员的积极性评审的目标的提高质量和提高整体水平，作者应该带着学习和提高的态度来参加评审。 代码集体所有制：对发现的问题要本着整体承担责任 的原则，因此建议把代码质量与团队绩效(而不是个人绩效)挂钩。 评审程度，进行一次整体的地毯式的评审成本很高。 代码评审的可操作性，首先需要评审团队具备经验丰富的系统架构师和精通业务的行业专家。其次团队需建立其开发规范或指南，在项目初期建立少量的sample代码与checklist为评审提供依据。 评审人员的职责是发现工作成果中的缺陷，并帮助开发人员给出消除缺陷的办法，而不是替开发人员消除缺陷 。 记录评审中出现的问题，跟踪改进。 评审前充分准备，评审后详细总结。 不要因为时间和成本问题取消评审。