搜索
六统一项目开发代码review管理办法1.1代码review增强项目经理的职责和要求（一）代码review完全依赖第三方部门集中review存在很多问题：Review人员必须了解非常详细的功能逻辑和程序对应结构才能对逻辑错误发现错误，工作量极大，项目多了的时候几乎不可能滞后性，对代码由专家委员会进行集中review会存在比较严重的滞后性，发现问题和改正错误的周期变长。统计数字：经过训练的工程师在代码评审时平均每小时能发现6.52个缺陷,2.96个缺陷在设计评审中.而单元测试则为2.21.[PSP资料]，做好项目开发过程中的代码review实际能够大大提高项目提交物的质量和提高工程师的水平（二）管理办法：代码review采用项目经理负责制，配合关键代码集中review的方法进行要求项目经理必须每隔2-3天就对项目组成员的关键代码进行review，及早发现问题，责令修改，尤其对于项目组成员有新员工和刚参加工作时间不长的员工必须进行review，并且要写review周报（使用下面的工具可以是Jupiterreview档案文件），作为项目经理提交能力的考核点之一。项目组内部在有条件的情况可以采用多人互相review的方法进行，采用专门的代码review辅助工具进行。相关生成的review档案文件要提交到项目的CVS中，作为公司对项目进行代码review工作考核的重要依据。对于核心业务模块的关键代码，涉及性能、安全、复杂逻辑的部分可以由六统一专家委员会进行关键代码的分析和review，以降低风险。检查方法分为2种：（1）项目经理申请进行代码review（2）六统一管理工作组指定关键模块进行代码抽查抽查的办法是主要是通过邮件列表，最后由六统一管理工作组汇总review结果，然后CC给专家组，出示意见，即时反馈给项目组,具体流程如下图：项目组专家组管理委员会决策层六统一工作组提交模块及相关代码获取整理打包获取和整理传送收集意见及整理代码review抄送修改决策要求、反馈汇报、通报、征求意见进行奖惩对项目经理问责行使相关的行政法令和奖惩办法反馈申请抽查（专家组代码review办法工作流程图）1.2项目组进行代码review的方法和工具使用1.2.1辅助管理工具1.2.1.1Jupiter公司目前大多数项目是Java项目，对于代码的开发管理平台目前采用EclipseIDE。而对于其他种类的项目也可以使用Eclipse来作为代码管理、版本控制和代码review的工具。我们要求使用的代码review辅助管理工具是Jupiter，它是美国夏威夷大学信息与计算机科学系的协作软件实验室在10多年软件工程研究理论的基础上开发的基于Eclipse开发平台的免费代码review管理工具。可以对项目的代码进行有效的协作式review管理。该工具是协作式辅助管理工具，项目经理可以按照安排总设计师以及有经验的开发工程师对代码进行定期的分工review。并且可以通过该工具将review问题分配到相关责任人，进行相关的修改工作。1.2.1.2Jupiter透视图基本面板介绍ReviewPerspective–提供review的透视图ReviewEditor–提供输入review问题条目的编辑栏ReviewTable–支持显示和修改已创建的问题。可以帮助用户看到所有review意见的概要内容，并且可以进行排序，还可以切换review的不同阶段Phasesection–提供不同review阶段的选择，分为：individual,team和reworkphase三个阶段，这三个阶段可以不断地循环迭代。通过选择不同的阶段，将自动切换到相关的reviewEditor和reviewtable中。1.2.2借助Jupiter进行代码review管理的过程和方法1.2.2.1工作组织项目经理：组织和监督项目代码review的工作总设计师：可以参与更多的review工作，并且将问题指派给开发人员解决和问题汇总。1.2.2.2角色划分对于项目组内的代码review角色划分方式有以下几种项目组比较大，技术水平层次差距较大可以集中指定几个技术经验相对多一点的技术人员作为reviewer，对所有项目关键代码进行全面review,并且自己也能对代码进行修改。项目较小，技术水平相差不大可以把每个技术人员作为reviewer，相互之间进行背靠背的代码review，然后修复自己发生的review问题。这个角色划分是相对的，项目经理或者开发组长可以灵活的掌握，保证代码review和修复的覆盖程度是最关键的，我们将对每个项目进行相关的审查。1.2.2.3review过程整个review包括这个阶段：1.2.2.3.1配置阶段在这个阶段，项目经理为一个工程（EclipseProject）的一轮review活动定义一个新的“ReviewID”，每个Jupitre代码review和一个Project相关。并且在配置ReviewID的时候可以指定该reviewID对应要review哪些代码文件，哪些reviewer参与review，并且可以设定review的档案文件以xml格式保存到那个文件夹（每个工程保存该工程的档案文件.review文件）当一轮review结束后，项目经理在发起新一轮review的时候可以新建一个ReviewID来标识新的review活动。并且每个reviewer必须将最近更新过的review档案文件提交到CVS系统，以便所有reviewer可以获得全部最新的review档案。1.2.2.3.2分别review阶段在这个阶段，每个reviewer都相对独立的进行review工作，并且对有问题的地方创建review意见，在jupiter中能很容易将意见和代码位置进行对应。在这个阶段，每个reviewer只能看到自己创建的review意见条目。当自己的这个阶段review工作结束就应该立即提交到CVS系统，让项目组长或其他reviewer看到你的最新review结果。1.2.2.3.3小组review阶段当每个人都创建各自的review档案后，经过互相沟通，就可以进入小组review阶段，每个人更新CVS就可以获得目前所有的review提交档案。每个项目可以根据实际情况，两两结对进行review意见的检查或者集中按标注对所有的文件进行检查和统一结论。对所有代码的review意见的优先级和重要性进行排序，将review意见指派给相关的reviewer进行修正或者监督修正。并且在小组review结束后将相关的档案文件进行提交CVS，以便进入下一个阶段。1.2.2.3.4修正review阶段在这个阶段，编写代码的作者（可能同时是reviewer）可以通过在该阶段中查看到相关的代码修正意见，并可以通过Jupiter迅速定位到代码问题处进行相关的修正和代码重构。在该阶段，对代码问题的修正状态也将反馈到review档案文件中。在每轮review过程结束后都将积累下相关的review档案文件，这些档案文件将随项目代码一起提交到公司的六统一中心服务器。最后这些review档案将对于新来的员工迅速提高提供宝贵的资料和实例，也同时在各个项目中可以积累更多的经验，可以将大家的经验变成全公司的经验，将可以持续地逐步提高强我公司项目开发的质量和降低风险。1.3代码review的基本原则1.3.1基本情况1、代码是否遵循编程指南（六统一颁布的开发编码规范）？2、代码是否有自我记录能力？能否通过阅读理解代码？3、是否已经解决了代码规则检查和（或）运行错误检测工具发现的所有错误？1.3.2注释1、注释是否反映了最新的情况？2、注释是否清晰正确？3、如果代码被变更，修改注释是否容易？4、注释是否着重解释了为什么，而不是怎么样？5、是否所有的意外、异常情况和解决方法错误都有注释？6、每个操作的目的是否都有注释？7、与每个操作有关的其他事实是否都有注释？1.3.3源代码细节1、是否每一个操作都有一个描述其操作内容的名称？2、参数是否有描述性的名称？3、完成各个操作的正常路径是否与其他异常路径有明显区别？4、操作是否太长，它能否通过将有关语句提取到专用操作中进行简化？5、操作是否太长，它能否通过减少判定点的数目进行简化？决策点是代码可以采取不同路径的语句，例如if-、else-、and-、while-和case-语句。6、循环嵌套是否已减至最少？7、变量命名是否适当？8、代码是否简单明了，是否避免了使用“技巧性”的方法？1.4附录1、《Jupiter用户指南》PDF可供详细参考Jupiter用户指南.pdf2、Jupter的安装文件