一.何为规则约束？
制定一些规则，来约束开发行为，来保障开发的正确性。
二.哪些规则？
>开发记录
根据自己的开发流程和环境，设计一些需要记录的开发点，将所有的重点和注意点都记录起来，无论是开发协同、后期维护都能提高很大效率，减少沟通的成本，一次沟通就要消费两方的时间。
所有的信息都应该聚合在一个地方，单独系统也必须附上对应的地址，使用说明。
>项目结构组织
- 根目录的第一层必须是模块包，模块之间进行区分，便于日后独立成微服务。各个模块包之间相互独立，不允许共享各自模块内的东西。
- 模块包内的结构设计，如果没有特殊情况，请保持和整体的统一。比如api，service，dao，model（po/vo/dto)，结构清晰，让新人也知道怎么做。
>开发流水线
比如：新功能XXX
- 数据库创建对应数据结构
- 反向生成对应的实体结构
- 引入对应的jar包
- 编写接口
- 实现接口：先写注释，再写代码
- 本地测试
- 单独提交分支
- 汇报工作结果
各种业务情况制作对应的开发流水线，能够做到新人上手即可复制，加速开发，节约成功，降低风险，规范代码。
>测试
- 环境要进行区分，本地开发测试，内测，正式环境测试
- 测试必须要写测试用例，每一群测试用例都要有主题
>部署
- 严重缺陷，以保障正确性为前提做部署，服务器直接更新覆盖，要求客户端用户更新APP
- 如果是升级，需要考虑兼容性的问题。如果只是应用层次发生了变动，那么只要为新版本适配上新的接口就做到了兼容。但是如果是一些底层变动，比如数据库结构发生了变动，这种其实是可以避免的，因为数据层的变动不应该影响到应用层，数据通道交互数据可以通过定义dto载体避免，至于数据结构底层的变更，尽量通过增加动作做到兼容（比如新建表承载全新设计的字段，表的ID字段等同于原来表的ID字段），当一定时限以后，关闭旧接口返回对应信息，前台提示信息，强制用户升级使用最新版本。上面的处理方式是基于一个用户只会使用某个版本的前提下，如果用户多处使用不同的版本，还要考虑数据的兼容，即无论哪个版本产生的数据都要能够得到正常展示，由于业务的变动，很难做到！如何能让新版本的数据适应显示在老版本上？至少我目前无法得到一个解决方法。总结下来：如果涉及数据结构变更只是增动作，那还可以做兼容，如果是删除或者变更，基本上无法做到兼容了，只能关闭原接口，强制用户升级最新版本。
