后端
代码注重质量，规范让世界更加美好
代码风格
检查代码是否存在格式问题，以及格式化代码。
注释
- 个人不喜欢太多的注释，要的是干净，像什么作者、日期通通不要，毕竟使用Git管理了，这些都是可追溯的
- 接口中定义的方法添加注释，接口的方法实现不加
实体类定义
实体类尽量不要复用，相关业务都创建相应的业务实体，解耦合，不要想着偷懒
一开始接触的是dao，但其实这是一个泛的概念，它泛指数据库层，其下就可以命名为DO类（和下方谈及的BO类同义），我认为实体类（entity）指代的更广，泛指所有的实体类
它可以对应一个entity包，包下放置和数据库相关的所有实体类（entity），包括：业务实体BO/数据库实体DO、前端模型VO、数据传输对象DTO
- 业务数据和处理（业务层中各种对象类型中间状态的转换需求）模型：BO（Business Object）是指业务对象，用于表示业务领域中的实体或概念，通常与业务逻辑紧密相关。BO包含了业务数据和操作方法，用于封装业务逻辑和数据处理。
（） - 前端数据展示模型（接口响应结果模型）：VO（Value Object）是指值对象，用于表示一组相关数据的集合，通常用于数据传输和展示。VO的属性通常是只读的，不包含业务逻辑，主要用于数据的传递和展示，以提高系统性能和可维护性。
- 后端接收请求参数模型：DTO（Data Transfer Object）是数据传输对象，用于在不同层之间传输数据。DTO通常用于将多个实体或概念的数据进行整合，以减少网络通信次数和数据传输量。DTO负责封装数据，而不包含业务逻辑。
数据库设计
统一规约
- 统一异常处理
- 统一响应格式
- 统一字面值常量
- 封装静态工具类
- 统一序列化处理：
- 敏感信息
Demo先行
有一件应该也不能忽视的习惯，那就是先写Demo
也就是说使用新技术、新方案的时候，引入依赖包整合之后先别急着去写业务代码，先去写个demo，emm可以当成单元测试吧
就是先写个示例看看是否整合成功了，环境是否有了？是否能实现我想要的效果？比如说FFmpeg转码，那我随便导入一个小视频，看看是否能正常转换各种编码，能才继续开始写业务逻辑
开闭原则
代码的开放性（Open/Closed Principle，OCP）是SOLID原则中的一个重要原则，它是由Robert C. Martin（又称Uncle Bob）提出的。这个原则的核心思想是软件实体（类、模块、函数等）应该对扩展开放，对修改封闭。
具体来说，这意味着你应当能够扩展一个实体的行为，而不是修改它。这样做的好处是，当你在不修改已有代码的情况下添加新功能时，你不会引入新的错误或破坏现有的功能。
一些符合开闭性原则的做法，例如：
- 责任链模式：通过使用责任链模式来验证注册用户请求参数，你可以轻松地添加新的验证规则，而不需要修改现有的验证类。新的验证类可以作为链条中的一个新环节添加。
总的来说，开闭性原则鼓励你设计出更加灵活和可维护的代码，这样可以更容易地应对未来的变化。
Git分支和版本管理
记录分支的管理方式，一个标准的参考，具体情况具体分析。而且下方图示，其实遗漏了一个中间分支的存在，也就是dev“开发分支”
项目大致的一个Git版控流程基础版本：
- master分支检出一个release版本分支
- 如果是第一次，应该检出dev开发分支
- 基于release分支检出dev分支，根据开发的功能模块开发人员再检出多个feature分支
- 各个feature分支的功能代码编写完成后merge合并到dev、release版本分支
- 当release分支开发完成功能趋于稳定，检出一个sit分支用来测试
- 当测试分支无误后，就是一个版本开发完毕之时就将当前的release分支merge合并到master分支
- 此时一个master分支就将是最新的分支代码，一般来说就是稳定运行的线上版本
- 当运行分支出现bug漏洞我们需要紧急修复就从master分支检出一个hotfix分支对bug做修复，修复代码后同样检出sit分支用做测试，测试无误后再合并到master分支
- 当需要版本迭代更新则再从master分支检出新的release分支，流程同上。
关于分支的命名和含义：
- release : 每次有新迭代版本开发(可跟随tapd迭代周期版本)，都需要从 master 分支中检出一个 release 分支,用作当前迭代的版本分支,命名规则为 release/迭代版本号 , 例如,当前迭代的版本为v2.0,那么用于开发当前迭代的分支命名为: release/v2.0 。release分支只接受 feature的合并请求。
- feature : 迭代需求开发分支，按功能点建立不同的功能分支，从 release 分支检出。命名规则 feature/需求版本号/功能名称 , 如：当前迭代有两个功能点分配给到两个不同研发人员，分别检出feature/v2.0/test1，feature/v2.0/test2。
- hotfix ：紧急bug修复分支，有需要时才新建。该分支是基于 master 分支创建的，开发人员在 hotfix 分支修改代码，开发完后需要合并回 sit 和 master 分支，同时在 master 上打一个 tag 。命名规则: hotfix/版本号/bug 名称
- sit ：测试环境分支，只接受 feature ，hotfix， release 分支的合并。研发内测联调通过后，由研发人员将自己的 feature 分支或 hotfix 分支代码合并到 sit 。该分支对应测试环境，测试人员的专用测试环境。
- dev ：开发环境，参考sit环境，可选分支（还是那句话看情况，他是否可选基本代表了两种分支管理的方案和流程）。
- uat ：预发布环境，只接受 hotfix 、release 分支的代码合并。（给客户演示用的beta版本，不是所有项目都有的）
- demo：演示环境也可以使用该分支
- master ：主分支，稳定版本代码分支，对外可随时编译发布的分支，只接受 hotfix 、release 分支的代码合并，由研发负责人负责合并。该分支对应生产环境，用于构建部署到生产环境。
可参考的项目分支管理结构：
每类分支是个文件夹下面按版本号再拆分，版本号下面是具体的feature
版本命名规则：
版本格式：v（小写）主版本号.次版本号.修订号，版本号递增规则如下：
从v1.0到v2.0：产品有一些质的飞跃；
从v2.0到v2.1：产品有大的变动，但没有质的飞跃；
从v2.1到v2.1.1：产品有变动，但没有大的变动；例如修复了线上某个bug。
标签命名规则：
每次发布生产(master)，都需要为master打一个tag，方便线上回滚,tag命名与版本迭代保持一致。
git tag -a v1.0 -m "v1.0需求开发"