[软件过程]软件设计规约

最新推荐文章于 2023-05-25 02:43:15 发布

古希腊小斑鸠

最新推荐文章于 2023-05-25 02:43:15 发布

阅读量589

点赞数 1

分类专栏：软件过程

本文链接：https://blog.csdn.net/cicocogood21/article/details/84026000

版权

软件过程专栏收录该内容

1 篇文章 0 订阅

订阅专栏

说点什么

本来准备晚上码两行代码的，后来发现太晚了，干脆来更新一下自己最近的心得好了。
今年我开始带后端的一些项目，项目开始之前发现部门里面好像没有找到一些类似Java设计规约的东西，我和另外几个新同事坐在一起商量了下规范后，大家就开始撸代码。撸着撸着设计和代码风格越来越多，项目质量也逐步下滑。特别是到项目后期，项目紧张起来，项目成员之间需要交叉维护代码的时候，画面惨不忍睹。
我琢磨了下，团队风格的不统一，其实也是意味着一个团队的磨合不够，会导致成员默契和配合度变差，规约这个东西还是得慢慢沉淀下来。
于是有了这篇文档，各位如果有什么建议或意见，欢迎给我留言。

设计规约

MySQL数据库设计规约

数据库表名、由用户定义的字段统一使用大写或者小写，不要大小写字母混用，建议使用小写
为避免阅读障碍，使用 _下划线间隔单词
每个数据库表必须具备id、create_time、update_time三个字段，id作为主键，create_time表示记录主动创建时间，update_time表示记录被动修改时间
所有的时间字段约定使用long（bigint）类型
表名、字段名长度不允许超过30个字符
主键设计，id自增慎用，避免oracle迁移麻烦，建议使用32位varchar，uuid生成（或者考虑snowflake）
不允许建立外键关系，只允许建立外键字段，外键自段必须以fk_打头，第二个字段描述外键业务名，如fk_product_id;
表名设备t_打头，第二个字段使用项目名，第三个字段为表业务名，如:t_project1_product

Git分支规约

开发阶段
开发在develop分支上进行开发
提测阶段
开发自测完成，将develop合并到release，提交脚本和说明
测试和Hot fix阶段
- 测试使用CI对release分支进行构建，并执行相关脚本，搭建测试环境
- 开始测试，提交bug到jira
- 开发在release分支上对jira上的bug进行修复，并提交验证
  （此阶段第二名开发成员可以在develop上开发下一迭代的new feature）
发布阶段
- 开发bug修复完成，测试验证完成，测试发出测试报告
- 产品经理验收
- 如验收出现问题，测试对问题进行复查，回退到第三步
- 如验收通过，开发将release的版本合并到master和develop，并打上tag
- 测试按规范梳理发布材料，正式发布

HTTP接口设计规约

采用restful接口设计规范
URL中为全小写，以“-”作为分隔
URL中的PATH为名词，严禁使用动词
GET、POST、PUT、DELETE增删改查
path设计规则：域名/模块名/版本号/XXXX，如http://www.github.com/device/v1/information等

附录知识

REST接口注意

最主要的问题主要集中在：什么时候使用POST, 什么时候使用PUT?
解释这个之前, 我们先解释下：什么叫幂等性?
幂等性是指：一次或者多次调用某系统/资源, 对资源造成的影响行为是一致的. 注意强调的不是说返回一致, 而是指对资源的影响是一致的. (请注意这个地方的理解)
一般来说, 只有不带唯一索引的INSERT(比如新增)和计算式UPDATE(计算式更新)是非幂等性的
回到问题本身, 我们约定：
POST主要用于非幂等性操作, 比如新增数据, 或者刷新会变动的二维码
PUT用于幂等性操作, 比如刷新不会变动的二维码