开发规范总结

此文是本人工作中总结的一些开发规范，比较粗糙，阅者不喜勿喷，不过可以提建议，谢谢！

一. 分支规范

1. 分支分类

        代码分支分为 master， UAT， dev， 以及各个feature分支，和每个版本的hotfix 分支。

        master： 部署生产环境的分支。

        UAT： 部署测试环境的分支。

        dev： 部署开发环境的分支。

        feature-xxx： 开发人员的功能模块分支，xxx 对应的是功能模块的简称。

        hotfix-Vxx: 每个版本交付后的补丁分支，Vxx 代码版本号。

2. 分支使用规则

         1)  开发人员从dev 分支checkout feature分支， 进行开发， feature分支的定义视情况统一创建或自主创建。

        2) 开发人员feature 分支要保持频繁同步dev 分支的代码， 至少每日早上要同步dev的代码，下班前推送自己的代码。

        3) 每个版本交付后， 会从UAT创建相应的hotfix-Vxx，开发人员自建各自的分支，hotfix-bug名称， 修复后提pull request 到hotfix-Vxx。pr 合并后，适时合并到UAT 供测试组测试。并且要将UAT合并到dev， 保证dev代码为最新。

3.Pull Request 规则

1. feature分支在功能模块开发完成或是开发到一定程度后， 提pull request 到 dev分支， 由负责人审查合并， 一次pull request 不宜超过10个文件改动，否则会增加漏查风险。提交时，要填写title，comment，comment中填入任务号（如果有任务号）。（ps：dev发布后，开发人员要跟踪下自己提交的功能是否正常发布）

2. hotfix 分支，bug修复完成后，提pull request 到hotfix-Vxx 分支， 由负责人审查合并，提交时，同样要填写好title，comment 等信息，comment中填入bug编号。hotfix-Vxx会合并到UAT， 供测试人员适时发布测试环境。（ps： UAT发布后，开发人员要指派测试人员去测试自己修复的bug）

3. UAT 分支会由负责人适时合并到master分支，发布到生产环境。

二 . 代码规范

1. 注释

为更好的协同开发，开发人员应养成写注释的良好习惯。 无论是go, python, nodejs， 都有自己的注释规范， 不做赘述，以下作一些大致要求。

1. 每个代码文件模块在内容最前面部分要有注释，说明该模块的主要功能或业务细节。

2. 每个类要有注释，说明该类的主要功能，类中的方法视情况补充注释。

3. 对于较为复杂或是篇幅较长的业务逻辑代码， 必须要有重要节点的注释。

4. README.md, 项目根目录应创建readme文件，说明项目概况、依赖、启动命令等。

2. 命名

命名规范，各种语言都有各自的规范，无论驼峰或下划线，按照主流的规范就行。作以下要求

1. 业务代码中， 类和方法的命名要紧密和业务名称结合，与项目或产品中的通用术语结合，这样更能达到直观的效果。

3. 架构设计

在这里主要只项目中代码模块的模块设计和层级设计， 后端代码因为会涉及到请求路由、业务代码、数据库访问、外部接口访问等，功能较多，所以要避免扁平化，要做好模块化、层级化，使架构清晰，增强拓展性和可维护性，也同样利于协同开发。

1. 抽取公共工具模块， 要尽量与业务逻辑脱离。如数值计算类方法，文件读写类等。

2. 封装外部接口模块，如对外有接口访问，这些应统一封装到一个接口模块。

3. 抽象业务基类，将代码中相似的业务类抽象出来作为接口供业务类继承或实现，这样对于后期新增的业务类叶能起到统一规范的作用。

审查人在每次合并pull request 的时候， 都应认真审查代码规范。