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

说点什么

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

设计规约

MySQL数据库设计规约

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

Git分支规约

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

HTTP接口设计规约

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

附录知识

REST接口注意

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

修改记录

1. 2018年12月19日：提交第一版本
2. 2019年03月27日：
   1. 添加HTTP接口设计规约
   2. 添加附录知识: REST接口注意