你的研发团队是否存在如下问题
- 程序bug不断
- 好好的功能换个姿势使用就出bug
- 开发好的功能，业务流程走不下去
- 每个开发人员写的代码风格各异
- 调试他人代码无比痛苦
- 接手他人模块代码无比痛苦
- 代码要不不提交，一提交一大堆代码
- 等等等
研发流程维度看问题
从上面的分析可以看出，可以从5个维度分别控制研发代码的质量，博主将分别以这5个维度讲解提升研发质量的方法。其中 “研发规范”、“代码检查工具Sonar”、“代码审核Merge Request” 将分别以三篇博文做介绍。本文先粗略讲解另外两个维度：“设计阶段”、“版本控制”
版本控制提升研发代码质量
代码管控的工作有很多种，早期大家使用SVN，现在大部分企业都用Git，使用GitLab建立企业自己的代码仓库服务器。为了契合企业自身的业务发展，有多种使用分支提交代码的方式，分别适用不同的业务发展特征。博主所在公司使用的是这种分支开发模式：Mast分支创建Dev分支，Dev作为过程版本分支每半个月一个，过程版本分支是用于不同项目交付使用的。新的Dev分支是在最新交付的Dev分支中拉取产生的。这种Git版本管控模式适合博主所在企业的业务发展模式(企业服务)。究竟哪些分支演进模式适合读者所在的企业，需要读者根据自己公司业务特征做选择。
功能设计规范化提升研发代码质量
要想研发的需求功能更可控适用，就必须把需求功能设计文档做好，设计文档分成两部分：一：PRD(产品需求文档)，此文档做好了，可以让开发者很清楚待开发的需求是干什么的，此需求将给谁用，解决什么业务问题。二：SRS(需求研发设计文档)，此文档作为研发人员针对PRD做的详细设计文档，此文档经过研发经理或者SE评审通过后，直接进入研发阶段，有了评审后的SRS护航，研发做的代码风向就不会错，再配合Code Review、自测、测试人员验证，产品需求质量就可以得到有效保障。根据博主多年工作经验，要想PRD\SRS产生较大的价值，必须要包含如下这些内容：
1）PRD：最后面一定要有针对此功能的实际业务人员使用的带场景的示例流程，这样可以给研发、测试指明此功能最终的服务形态，也是研发自测的依据。
2）SRS：SRS做的越细越好，但是究竟要多细呢？究竟要包括哪些内容呢？ SRS内容至少要包括如下内容：详细的接口文档、物理模型PDM、新增修改类的UML图、指明是新增类/方法 还是 利旧已有的原子化类方法、要实现的业务逻辑的详细描述。
上面简要描述了保证研发代码质量的两个方法，这两个方法跟各企业的业务特征、研发流程规范关系较大，故不再做跟细粒度的介绍，读者需要根据自己企业的业务特征做细化。下一阶段博主将以3篇博文详细讲解“研发规范”、“代码检查工具Sonar”、“代码审核Merge Request”，这些内容网络上的博文较多，但博主更多的是介绍 为什么用这些规范工具、怎么用这些规范工具、用这些规范工具能达到什么效果。 欢迎大家邮件交流：[email protected]