关于 Code Review

 Code Review

  Code Review做为预防措施,避免修改一个BUG引入多个BUG的情况发生,前期减少缺陷,提高版本质量有很大的帮助.

 

当进行工作移交时我们会进行 Code Review，在碰到棘手的BUG时也会进行Code Review，Code Review是大家了解其详细实现的一个好机会。在Code Review之后会对此代码产生亲切感而不是陌生惧怕感，相信很多人在读他人代码时会有非常痛苦的经历，Code Review是减少此痛苦感的好药方。在进行Code Review前，主讲人会提前发出一个通知告诉相关人员要review哪些代码，这样参与者可以抽出时间提前了解相关代码，对不懂的地方做个笔记以便在 Code Review进行中提出疑问。在我们碰到比较棘手的BUG没有什么思路或大惑不解时，这时找几个相关人员或对此代码也熟悉的人进行一次Code Review，这时形式比较随意，大家可以临时提出问题，让主讲人解答，在这个过程中可能听的人并不会非常快地了解其中的详细过程，但是讲的人在这个过程中重新理了一下思路，对所写的代码被迫重新审视了一遍，在其中可能就会发现出解决问题的办法。在Code Review时有时代码非常多，但可以一个功能模块一个功能模块地从总体到局部，由浅入深层层递进的方式进行。一次Code Review的时间不要太长，但可以分多次进行。Code Review中大家会提出问题和建议，集思广益，多个人共同出主意，有些可能一个人没有想到的问题会被大家发现，互相学习，共同进步

Code Review的原则和方式

1.代码评审的原则:问题比较多,影响比较大的插件或者模块.评审人员不超过4人,3人为最佳.其中一个为评审组长.

2.评审的方式有两种:1.在座位上进行评审,2.进会议室评审.(预研性的功能和新功能)

3.由于组织前期对流程理解比较薄弱,QA可以参与进来,保证一方面大家做代码评审,另一方面保证做的质量,待大家养成习惯后,QA退出.

4.对单元测试单进行修改.强调修改的内容和影响的分析.保证测试人员对修改内容的充分了解.

5.版本发布前,需要有本人提交:评审组长签字后的单字做为版本发布的依据.

具体操作步骤:

  1.  开发人员学习设计文档和需求文档，理解所要编写或修改的模块相关的内容

  2.开发人员使用要求的开发工具和开发环境，根据设计文档的内容，遵循规定的编码规范，进行编码；调试(流程性测试)完成以后，由开发人员发起，进行同行评审

  3.研发工程师邀请涉及此模块的相关人员进行Code Review.例如通讯某一模块涉及到前台和后台的两位工程师,通讯工程师邀请两位在逻辑关系,接口调用等给予重点讲解.两位工程师给予意见.

  4.代码评审结束后,并认为没有问题,方可提交代码至代码库中中.

一般来说，建立代码基线以后，代码的提交需要严格控制，在建立基线之前，代码可以随时提交