开发规范
一、统一定下规定
1、异常处理
异常处理基础[https://www.cnblogs.com/loveis715/p/4596551.html]
自定义配置异常方式：
controller异常处理切面配置方式：
拒绝try catch以后什么也不干，也拒绝满篇的try catch。uncheck exception交给切面处理，返回统一的格式。check exception再由各自处理。
2、返回格式
所有业务代码返回前端的格式应统一，拒绝每人一个返回方式，状态码应提前约定好，根据项目提示信息也应做成枚举，统一管理。
3、代码结构
后端确定架构方式以后，搭脚手架的同时应设计好代码机构，并且能形成文档，代码的划分的依据是什么应形成文档。团队协作，各干个的同时，首先要遵循统一的规范，其次代码的交叉部分更好沟通交接，在人员代码解耦的同时，做好复用和避免重复工作。
基础功能的开发，应放到基础包下，往里面加可以，不要自己写到的包里。
4、规定统一的技术
项目代码要想层次分明，阅读性和耦合性低，就得统一规定技术。绝对要杜绝，团队中的人每人各搞各自己熟悉技术。小李喜欢写mybatis，小张喜欢jpa，结果都引进来。一个乱字了得。
二、命名
1、mysql命名
mysql字段：因为win下区分大小写，linux不区分，所以mysql下所有命名都应该统一以下划线为分隔，单词能基本反映意思。还有，写sql的时候，起别名是应该遵循，数据库表别名规则：取首字母，如果出现重复别名，最后一个字母后继续再取原单词的下一个字母，如果还有重复，继续取下一个字母
2、Java字段、函数、类名、包
Java中的命名全部使用小驼峰，Java中包名也应统一，最好统一成小写。
单个的项目，最好基础的服务全部放到一个总的包下，然后根据细分再划分包。
包的作用就是目录和索引。划分时要根据项目实际，比如根据业务模块划分包、根据前端展示划分包、根据每个人做的划分包。然后controller的命名最好是也有根据，名字起得一看就能懂。比如，我们一级包名根据页面一级菜单，二级包名根据二级菜单去起，然后controller的命名再根据三级菜单，一个controller下只写这个页面相关的接口。这样下来，既可以通过页面能找到接口，也能根据接口名找到所在的包。
3、url
url首先应该在入口有统一前缀、然后每个一级的包前缀、controller前缀、再到具体的接口，所有的命名应该能反映出业务。能在没有搜索的功能下，根据url找到对应的接口。
三、项目分层
一般web项目都是三层结构
controller：控制层，只可注入service；不写业务，最多写校验和返回体的格式化。
service层：业务层，可注入任意，主要写除数据层的业务代码。
dao层；数据持久层，组要写持久化操作。
项目分层的目的就是解耦，每层的函数单独拿出来让人一看就知道大概是什么功能，首先应该拒绝参数透传，就是从控制层接下一直到dao层都是一个pojo或者json，这样我们要想知道功能，首先得看接口文档，没文档得去页面看，也不知道具体的功能。
个人建议：
1、controller和service使用DTO传，service和dao用entity传。
2、参数校验全部在dto做，方式可以统一规定或者自己写。
3、每个数据库表，都有唯一的entity与之对应，并且是不可以随意加删字段，除非表更新，跟着表一起更新。
4、链接查询所需要的联合表的entity，要根据联合表名起，中间加上union。绝对可以共用。
四、文档规范
1、接口文档
一份好的接口文档，在前段和后端对接时基本不用交流。
应该包括五个部分：
1、url和请求方式
2、能请求成功的请求示例（多次对接发现，写完都没试，就提供出来了）
3、请求参数说明（字段类型、是否必须（哪些是做了参数校验的））
4、返回示例，请求示例返回的数据。
5、返回参数说明。
6、备注；比较复杂的功能在这说清楚。
2、数据库设计文件
数据库的设计，囊括了整个项目的功能设计，看懂数据库，大家协助才能更好地明白整个项目功能，才能更好的协作。
powerdesigner要存下完整表结构，注释每个字段功能，注释每张表功能 ，每次和主库同步，增加字段，修改表结构、增加表都应得到记录。
3、需求文档、设计文档、会议记录
1、需求文档
需求文档是站在产品角度写的关于需求的实现，关联产品原型图。是设计的整体概览和外部展示。
2、设计文档
设计文档是站在后端开发的角度去设计实现，是具体的逻辑设计思想。文档完成后可以清晰的看出你设计的思想，没有codereview时，这个是对项目把关的重点。
3、会议记录
每次开会，所商量的东西最好形成书面文字，日程和变更记录更要形成书面文档，让每一次会议整个团队大家都有去了解的地方，不然开了很久的会，一不小心就是过眼云烟。好点的结果就是参与人员知道会议的结果。人员一旦离开，就是带着会议离开。后面接手的人就要再重新去把坑踩一遍。说不定，兜兜转转一圈后，又回到起始位置，知道为什么这样设计了。
五、codeReview
codeReview只有在实施过以后，才知道这个东西的好处，把握提交远程库的质量，有人对设计思路了解，可以对代码设计和问题和有些坑扼杀在摇篮。坏处就是需要有人花费时间在上面，而这个人必须得是个编码经验丰富的。
