软件质量管理之一：总体开发规范(数据工厂)

1、概述

1.1编写背景

    介于当前部署时版本不明确，部署流程不健全；系统划分不规范等影响商务合作、客户运营人员使用等问题，为了演示更流畅，部署更便捷，系统边界划分更清晰，现针对以上存在问题，做以下相关规范，以达到提升系统可用性、流畅性，提高系统质量的目的。

1.2 阅读对象

    本规范阅读对象为各平台开发人员、产品经理、项目经理，及各位后端组长参考。

2、数据库设计规范

2.1 数据库

2.1.1 建库规则

    数据库建立是要以平台为单位创建，便于统一管理和查找，也会减少不同平台间公用某系统表等问题

2.2 数据表

2.2.1 表的归属

    当前一个数据库中包含了多个平台的数据表，部署时需要与研发确认需要那些表，为了方便运维、提升部署效率，建议以大平台为单位建立数据库，比如：数享平台、地市分析平台可以分别建库，有时候出现特殊项目是也可以独立建库，如核酸检测和疫苗预约项目。

2.2.2 表的命名

    目前已有的表的名称大致有三种方式：

• t_+模块名称+表用途，t_indicators_audit
• 平台简写+模块名称+表用途，acs_assets_request
• 模块名称名称+表用途，例子data_asset_level

数据库名如果已经使用了平台名称，考虑有时候表用途英文较长，建议使用上述第③种方式命名数据表。

2.3 表字段

使用简短英文表示，不宜过长。

3、代码编写规范

3.1 业务模块归类

        目前一些平台还存在包含其他平台模块的情况，对于还未归类的平台，后续根据实际情况，逐渐做好归类工作，对于已经归类的如数享2.0，需要严格把关，不接非本平台的模块，保持各个平台独立、纯净。

3.2 代码层级规范

现状：目前总体分为两种层级管理方式

方式一:每个模块建立一套相同的层级块

方式二：模块公用一个层级块

建议新建项目以第二中方式为准，减少文件夹创建，便于快速查找文件。

3.3 流程图

对于复杂的业务流程，需要绘制对应的流程图，一来可以知道自己开发，二来可以可以方便其他同事修改。

4、版本管理规范

4.1版本命名规范

现状：各个平台基本分为了dev、demo、master、其他版本四类，其中dev为开发环境，demo为演示环境、master为主干分支，其他版本属于个人根据项目部署情况，自行定义的版本。

由于各个版本命名不统一，导致部署的程序与sql、配置文件不兼容，导致演示问题频出，所以需要对版本号建立做一个规划，分为4个分支，分别是dev、sit、demo、master四个分支，dev为总的开发分支，每次有模块迭代，需要从dev分支拉取一个分支作为迭代分支，建议命名[dev+版本_+模块_+上线日期]，如dev2.0_datafactory_20220325。

4.2版本合并前准备

在版本合并前，由项目开发负责人将当前版本发布的内容发给对应开发、测试、产品和相关领导，大家对当前版本做一个评价，列出本版本完成的任务、遗留问题和处理方式，确认无误后进入发布环节。

4.3版本合并原则

如果本次发布涉及多个模块，以主要改动模块版本为所有改动模块版本号，便于控制变动范围、出现问题时候方便查找处理。

版本合并原则

1、每次同一个项目开发新版本，需要开发人员从dev拉取开发新的开发分支，命名[dev+版本_+模块_+上线日期]。

2、开发自测完成后可以自行合并到dev分支。

3、dev经过测试验证后，由开发人员在git发起合并请求，项目开发负责人接到请求后合并到demo分支。

4、项目交付后，由项目开发负责人自拉取demo合并到master,并将增量配置合并到项目全量配置中，完成当前版本存档。

5、如果在测试工程师测试发现问题后，可以在当前开发分支修改，也可从dev分支拉取dev当前项目版本bugfix分支[dev+版本dev+版本_+模块_+上线日期_bugfix]进行问题修复，完成后自行合并到dev分支。

6、重复3、4。

4.4版本合并申请

1>进入项目git找到该项目，创建合并请求。

2>选择预合并分支，目标合并分支。

3>添加本次修改的配置文件、sql文件附件，此处文件为增量配置文件。

4>填写需要提交合并的人员信息，创建合并请求。

5>项目开发负责人收到请求后，合并代码和文件，将全量的配置更新到对应分支。

5、私服打包

2.1 原则

在lib包还未稳定前，使用SNAPSHOT版本，稳定后准备发布使用RELEASE版本

2.2 lib包命名规范

dev2.0 _20220225_SNAPSHOT

dev2.0_20220225 _RELEASE