SVN代码质量管理指南

Posted 2021-05-01 我爱我嘉2000万

继上次研发管理工作指南，按照每个季度解决一个问题的思路，第2季度我们整理了SVN代码质量管理思路，遵循小而美的迭代，具体如下：

一、    问题

研发代码质量 = 研发人员编码能力 + 研发人员业务理解深度

1.  研发人员的编码规范不够统一，研发人员没有编码规范的指导或者没有按照编码规范去执行；

2.  研发人员之间的编码能力会有差距，但差距的补救措施我们可以好好去思考，去想办法让能力稍差的人逐步提升；

3.  研发人员具体做业务模块开发时，因为种种原因并没有完全理清业务需求中的逻辑关系，特别是跨模块，跨子系统之间的业务关联。最终交付测试时，结果就是缺陷较多。

二、    改进思路

抓住代码质量可提高的变量，总结可复用的经验，形成相关指导规范。

1.  研发人员编码能力提升，我们从外部提供一些改进方法，激发研发人员自身原动力，比如：按开发语言编制编码规范指导手册，加强SVN代码管理（包含代码提交规范性，注释），核心组件代码评审，详细设计文档评审；

2.  研发人员业务理解深度提升，核心组件，功能开发时，需要产品工程师，研发经理做详细的需求澄清，数据库设计，详细设计指导，最终以研发人员能够完整复述对需求澄清的理解。

三、    具体优化措施

1   编码规范

优化事项	操作思路	责任人
Java开发编码规范	采用研发管理部的基础班进行修改	XXX
C++开发编码规范	采用研发管理部的基础班进行修改	XXX

2   代码管理

优化事项	操作思路	责任人
代码提交规范	参考第四部分的原则说明	研发人员
核心组件月度评审机制	如有必要，每个月研发经理从开发的项目中选定核心组件，组织同行评审详细设计文档和代码。	研发经理

四、    代码提交规范

4.1 基本原则

一．提交之前先更新

二．保持原子性的提交：每完成一个小功能都进行一次提交，重要功能提交都需要经过测试部验证，不要等积压多个功能一起提交。

三．提交文件都必须是有效的，不需要把中间文件上传。

四．提交的代码必须是可编译，经过自测的。

五．提交代码时需要标注详细的注释。

 

4.2 提交注释

以举例方式说明：

[缺陷][功能组件][一级需求][提交者]

修正了……问题。

BUG来源：测试部，客户或者自测等

BUG重现步骤：填写青铜器 bug_ID，如果没有则简要说明重现BUG步骤或场景

 

[新增][功能组件][一级需求][提交者]

增加了……功能。

原因：(注明增加新功能原由，比如产品规划，客户需求变更。)

[删除] [功能组件][一级需求][提交者]

删除了……代码。

原因：……(注明删除原因)

 

[修改] [功能组件][一级需求][提交者]

改进了……功能。

              改进原因：……(需要注明原有功能存在问题)

 

[移植] [功能组件][一级需求][提交者]     

移植了……代码。

原代码路径： (需要注明移植代码出处或开源项目)

 

[恢复] [功能组件][一级需求][提交者]

恢复到(还原到、回退到)……r1234。

 

[合并] [功能组件][一级需求][提交者]

合并目录svn://172.16.16.10/Smart/branches/v1.1.0中r8347-r8349的代码

 

[文档] [文档类型][备注][提交者][审核者]

新增，修改，更新，删除XX文档/章节。

 

是否需要审核，也需要看情况， 研发经理不可能对每块代码都很熟悉，对于编码能力很强的同事就弱化质量监督，做到进度监督就行了。

 

3  记分事件

代码质量管理指南，设定一个过渡期，给予大家大家一定的适应时间，由6月份的第一周正式执行，期间研发执行不到位的，有研发经理多强调，甚至例会中提出批评。6月份执行过程中，由QA监督执行，发现不正常的，由QA报研发经理，由研发经理决定是否记考核事件。记分原则很简单：除编码规范考核很难量化外(这块由研发经理量化)，代码管理中的“基本原则”，“提交注释” 没出现一项记1分。