业务实践系列(4)：项目开发常规规范

最近先后接手了 2 个项目，接第一个项目觉的好乱，花了好几天略有理清；接第二个项目时觉的第一个项目还行，就这样认知底线又被突破。

一个没有规范化的团队和项目，项目经过多人多次迭代，简直是一团乱，属性、方法、表字段命名不规范，表关系设计不清晰，Mapper 层与业务强耦合，注释与实际功能不一致，业务包结构不规范，公共功能不抽出独立，新人接手难以通过代码快速了解业务，真是太糟糕了。

本篇基于个人在项目中遇到的以上原因而记录需要的规范。

1. 属性名必须遵循驼峰规则。

2. 表对象及字段名必须是小写，多名用下划线连接。

3. 表关系设计必须明确一对多，多对多的关系，必须明确主表，子表的关系。

4. 微服务架构会有很多远程调用，将所有远程调用抽取到一个公共服务类转为本地接口服务。

   在一个类里一目了然知道有那些远程调用，若都散落在业务里面，若有新的地方需要使用则难以查找数据来源，几乎不可复用。例如定义一个 RemoteService 或 CommonService 类。

5. 微服务架构的微服务之间调用，严禁开启事务，极容易出现死锁且不好定位排查。

6. Mapper 层一定一定必须是与表强关联，而不是与业务关联。

   对一个表的所有操作都必须落在一个 mapper 文件中（多表情况跟主表走）。否则与业务关联，则各种 mapper 文件，极可能存在重复的 SQL，不便于理解业务。

7. 必须有一个实体类，属性与表字段一一对应，在 Mapper 层接收 SQL 查询结果的对象尽可能向实体类靠拢，便于 SQL 复用。

   VO 尽量控制在 Controller 层，业务层尽可能使用实体类或 BO 处理数据，便于复用。

8. 如果业务层的设计不能满足 开闭原则，则尽量不要深层封装，否则后期极难维护。

9. 业务实现，尽可能选择简单的方式来实现复杂的业务，易于阅读和理解。

10. 对表的 CRUD 操作的方法统一方法名前缀，便用快速查找。

• 查：select，query，get，find，list
• 增：insert，add，save
• 改：update，change，modify
• 删：delete，del，remove。