代码REVIEW的流程化工作

一、CODE REVIEW工作组织建立

      代码REVIEW的工作，多数人认为是程序员的事情，其实恰恰理解的不充分，代码作为软件最基本要素之一，仅仅是之一，软件其实还有很多方面，设计，推广，销售，服务等等都是软件的要素，这些都不是一两个人全包就可以解决的，所以要有不同的人，形成组织。REVIEW代码同样的道理，代码实现的上一级，一定是设计，设计师要不要参与，有没有按设计师的设计进行实现，实现过程中有哪些问题设计没有讲清楚的，设计师要参与，代码编写完了有测试工作，模块测试，层级测试，功能测试等需要测试人员参与，特别是白盒测试，更是需要对代码有一定的了解。质量管理人员对质量的把控同样是需要了解代码中有多少问题，质量过关没有项目经理更是要了解，代码的BUG和修改对项目进度的影响，上面描述的角色都是利益相关人，所以组织一定是要有的，只是主角变为了写代码的程序员。

二、CODE REVIEW流程化方法

1、REVIEW策划

【确定REVIEW CODE的范围】

       一个软件项目，代码量还是有些的，特别是大的软件工程，百万行代码是很常见的，所以，一次代码REVIEW的规模不能太大，可以进行多次的REVIEW活动，每次只针对特定模块，一次性REVIEW清楚，防止多个模块或层次交叉在一起，REVIEW不清楚，导致REVIEW效果低下。

 

【确定REVIEW的人员】

        此模块代码实现程序员，关注的重点是代码是否正常，功能是否实现，逻辑算法是否对，REVIEW的人员能发现点代码的问题，以及解决的思路。

       使用接口的人员，测试人员，高 层模块使用低层模块，此类人员关注的是模块接口是否好用和使用的限制，测试是否方便。用户技术支持人员，此类关注的是模块接口是否有扩展性和易用性

       此模块算法和设计人员，此类人员关注的是算法实现有没有设计问题，代码实现好不好，算法的效果如何，设计人员关注的是流程是否正常，调用关系是否正确。

       关联模块的设计 编码人员，提供基础模块的人员，此类人员关注的是你调用我的接口有没有调用错误，调用的先后次序等

。。。

从上面可以看出，程序员要想把CODE REVIEW做好，还真不是件容易的事情。

 

【确定REVIEW的要求】

        很多程序员都把REVIEW代码认为是找BUG，格局太小，REVIEW代码找到BUG只是其中的一部分，REVIEW代码过程中可以检查的东西很多，代码实现功能的完整性，异常处理有没有，接口定义有没有按公司的编程规范，接口在日后的扩展性上有没有考虑到，代码逻辑是否合理，算法是否选择正确，算法是否太复杂等待都是可以进行REVIEW的，这都是CODE REVIEW。

        要求一定要提清楚，REVIEW CODE重点是什么，不同的模块 REVIEW的重点业务不同的，比如： API接口代码的REVIEW， REVIEW的重点在接口的易用性和可扩展性上，实现关注是否多任务调用，同/异步调用；模块代码的REVIEW重点在于模块功能实现是否稳定可靠；算法代码的REVIEW重点在于算法是否正确和效率。

 

2、REVIEW的实际实施

【确定REVIEW的活动时间段】

一般建议代码快写完的前几天启动REVIEW工作

 

【落实REVIEW活动】

REVIEW的形式选择

1、  代码离线REVIEW，相关的人员通过配置库获得权限，获取版本代码，代码检查，提出问题记录，代码实现人员回答。当然也可以通过即时通信工具，线上直接问题，也可以将记录发给代码实现人员。有些公司有REVIEW的工具可以使用，如网上问题单形式的，有EXECL表格，还有直接使用SOUCEINSIGHT插件的等等，视情况而定。

2、代码串讲会议形式（网上会议也是此类）

      此类形式最值得推荐，但要控制好人员规模和时间，会议效果才会得以体现。预约会议室（有时会议室挺难抢的）后，发会议通知给相关人，附带CODE REVIEW的要求和资料，提前让大家有个准备。会议前可以收集一些反馈。会议正式开始使用大屏幕进行相关代码的REVIEW。

       会议过程建议，程序员先讲一个REVIEW的要求，第二步讲代码实现的功能规格，第三步讲实现的大致流程，以及和周边模块层次的关系，第四步开始自己代码的讲解。讲解的过程中，可以随时打断进行交流，同时程序员需要将一些关键点记录下来。

程序员执行的工作：会议前准备CODEREVIEW的资料和代码和讲解思路，会议预定通知，会议中讲解，问题和关键点记录

REVIEW的人员需要执行的工作：会前了解REVIEW的内容，这点很重要，代码现场看效果比较差，除非你能力够强，虽然有时不一定能看懂，但基本的API，业务流程，语法和编程规范都是可以看的，基本的调用关系都是可以事先看的，甚至和自己相关的接口。会议中集中精力，按业务流程对应程序员代码串讲过程，在串讲的过程中，不同人看事情角度不同，很容易发现问题，及时发言，讨论交流，记录关键点和问题。

3、结对面对面形式

        这种比较适合组员，人数一两个，可以随时在电脑前进行，这种在软件代码还没有成型的情况下，或代码都一定编写难度，中间写不下去了，通过这种方式REVIEW代码，也可以很好地解决代码问题。

【收集REVIEW的反馈】

       REVIEW的过程到这里，主要的过程已经结束了，不管反馈是邮件，还是会议记录，随笔，需要一个整理的过程，内容按对内和对外两部分，对内是自己需要进行的工作，对外主要的求助和要求。

【确定修改方案】

       对于REVIEW出的问题，代码的BUG和功能缺陷是需要程序员自身出方法来进行解决。对于涉及架构和相关模块的设计就需要单独形成软件任务，要求相关的人员提供解决方案，并且一定要知会到相关人。

三、REVIEW评估

        这一部分，多数项目是没有的，一个是流程本身很多项目就没有，另外一个没有将REVIEW结果转化为对项目的贡献，主要是不是显性的，其实最应该有的就是对当前项目的影响最重要，要有对项目中上游环节和下游环节的人员和部门的影响说清楚，代码中的问题是否影响架构和设计，设计本身也有可能有问题，只是设计期间没有暴露出来，到代码实现阶段问题出来了，设计人员部门需要进行补充修改设计。

        程序员之间的代码影响，这个比较直接，调用的接口，算法调整相互知会，当然REVIEW过程中可以当面确认。比较有经验的程序员，会将问题和REVIEW的修改结论写到一个TXT文档中，放到软件项目工程中，这个是历史记录，对日后维护代码非常有用。测试人员知道代码中的问题，会相应增加测试用例，覆盖测试和回归测试，相应的工作任务也就很明确了。质量控制人员可以通过历次的REVIEW活动的记录，量化出软件项目的质量水平，相应提成质量控制方法，如设计力量不足导致代码实现问题多，需求不清楚等等。

       最后是项目经理，有没有影响到项目进度，人员是否调整，协调资源等工作。

 

如何进行代码REVIEW

代码REVIEW的一般方法