软件开发的基本规范

小橙子616
81 阅读5分钟

对软件来说，适当的规范和标准绝不是消灭代码内容的创造性、优雅性，而是限制过度个性化，以一种普遍认可的统一方式一起做事，提升协作效率，降低沟通成本。

命名规范

  • 规范：命名规范-强制执行
  • 说明：为解决sql语句查询命名冲突，java类命名含意不清晰问题，定义以下命名规范（方式）
    1. 确认sql查询，java类的主体。比如：user 用户【以下基于用户为主体的命名】
    2. 简单命名：主体内容命名采用简单命名，比如 id = 用户编号。name = 用户名称。status = 用户状态
    3. 完整命名：非主体内容命名采用完整命名，比如 school_id = 学校编号。school_name = 学校名称。school_status = 学校状态。
    4. 无法确认主体的sql查询，java类，全部采用完整命名，不允许出现 id, name, status 等命名方式。
    5. 表字段 为下划线规范，类为驼峰规范。两者已经实现自动转换
    6. 表名、字段名必须使用小写字母或数字，禁止出现数字开头，禁止两个下划线中间只出现数字，禁止使用驼峰命名
    7. 表名不使用复数名词
    8. 字段禁用官方保留字
    9. 唯一索引用 uk_字段名 ，普通索引用 idx_字段名
    10. 表名前应该加上前缀，一般为：业务名称_表的作用
    11. 日志表均以_log后缀
    12. 临时表要以tmp_前缀，以时间后缀, 备份表要以bak_前缀，以时间后缀

数据库字符集规范

  • 规范：数据库字符集规范-强制执行
  • 说明：数据库字段字符集不一致，无法使用 = （等号）操作符，索引效果不理想。
    1. 数据库字符集全部统一使用 utf8_unicode_ci
    2. 在要求大小写敏感的一些地方，可选用 utf8_unicode_cs

数据库表设计规范

  • 规范：数据库表设计规范-强制执行
  • 说明：为提高数据库运行效率，规范数据库表设计，特定义以下规范：
    1. 表必须定义主键，默认为ID，整型自增（如果有特殊情况，可商讨后自定义）
    2. 禁止使用外键，一切外键概念必须在应用层解决
    3. 多表中的相同列，必须保证列定义一致
    4. 每个表都要有基础字段，并放在业务字段之后
    • 排序（sort）
    • 创建时间（create_time）
    • 创建人（create_by）
    • 修改时间（update_time）
    • 修改人（update_by）
    • 备注（comments）
    • 版本号（version）7个字段。具体字段设计可参考表demo_types，sort字段后的全部字段信息（包含sort字段）。
    1. 小数类型用decimal（禁止使用float和double），如果存储的数据范围超过decimal的范围，建议将数据拆成整数和小数分开存储
    2. 如果存储的字符串长度几乎相等，使用char定长字符串类型
    3. 每个字段都要有明确的注释，当字段的定义有修改时，要及时修改注释信息
    4. varchar长度设计需要根据业务实际需要进行长度控制，禁止预留过长空间
    5. 需要join的字段，数据类型保持绝对一致；多表关联查询时，保证被关联的字段需要有索引

注入风险管理强制

  • 原则：注入风险管理强制-强制
  • 说明：防止一切注入风险：
    1. 【重要】orderBy 中使用 ${}。必需使用 setOrderBy 传入，已经添加风险控制
    2. MBG 的 noValue，singleValue，betweenValue，listValue 注入风险：Example 的 Criteria 产生，无注入风险
    3. MBG 的 like 注入风险：like 前的由 Example 控制，后的为 #{}, 无注入风险
    4. 【重要】Custom 实现的 like 强制使用 AND column like concat("%",#{value},"%")

分支命名规范

  • master: 最新稳定分支，上线后的功能，需要合并到 master
  • release/yyyyMMdd: 历史稳定分支
  • feature/user_define_feature: 特性分支，自定义名称即可

分支合并规范

  1. 新需求：需要从 master 检出 feature分支进行开发
  2. 上线：从 master 检出 reelase/yyyyMMdd 分支，再将不同的 feature 分支全入 release 分支，发布上线
  3. bug修复：从对应的 release 分支中检出 feature 分支，修复后合并到 release 中发布
  4. 发布完成：从 release 分支合并到 master，完成一个周期

提交记录规范

  • feat 新功能的开发

  • fix 修复问题/BUG

  • style 代码风格相关无影响运行结果的

  • perf 优化/性能提升

  • refactor 对已有的功能进行重构

  • revert 撤销修改，撤销上一次的commit提交

  • test 测试相关

  • docs 文档/注释及格式的改动

  • chore 依赖更新/脚手架配置修改等

  • workflow 工作流改进

  • ci 持续集成

  • types 类型定义文件更改

  • build 改变了build工具

  • wip 开发中

  • 示例

fix: 修复图片显示异常

代码提交过程

  • 使用提示：代码管理-强烈推荐
  • 说明：为防止版本管理上，代码会错误 merge 而被覆盖的问题，需要按照以下步骤进行操作：
    1. 把不需要提交的代码还原掉
    2. 把需要提交的代码提交到本地 【commit】
    3. 拉取 gitee 上的代码 【pull】
    4. 处理冲突【按照上面步骤操作，冲突将针对是最少的】
    5. 将代码推向 gitee 【push】
avatar
文章
阅读
粉丝