个人代码规范

:之前和其他团队进行合作。由于不同团队的编写水平不一致，导致很多地方需要重新架构，其实难运维的原因，大部分原因是代码不规范，所以在修改的过程中，觉得还是把自己的代码习惯整理起来，便于以后进行查看，当然作为JAVA开发者，规范的第一圣经就是《阿里巴巴Java开发手册》，在这个基础之上，又增加了自己的代码规范

规范的前提：程序员一定要有代码洁癖，才能对自己写的代码要精益求精

1.一个方法只做一件事或者一个方向的事情
1） 获取单个对象的方法用 get 做前缀。
2） 获取多个对象的方法用 list 做前缀，复数结尾，如：listObjects。
3） 获取统计值的方法用 count 做前缀。
4） 插入的方法用save/insert 做前缀。
5） 删除的方法用remove/delete 做前缀。
6） 修改的方法用update 做前缀
个人的习惯 赋值 set；判断 is;避免类set方法冲突，也会采用put

2.查询的方法
1）方法的最后使用By描述具体一个变量的方法(同名方法只是条件不同)
getCheckRecordByUserId()

2）如果存在多个变量的方法使用中间使用with进行描述
getCheckRecordByUserIdWithCompanyId()

3）超过五个变量使用DTO

3.多步骤的方法
1）多个处理可以按照处理的顺序进行命名；
saveAbnormalAndRemoveCheckToday
2）如果步骤过多就使用最外层或者主体逻辑命名方法，但是注释一定要描写清楚
3）不同分支的方法，即使只有类型不一样，主体逻辑一致，但是在业务上有区分，一定要在外部再添加方法进描述，内部主体逻辑复用，也不能使用ifelse 进行处理
如图内部处理逻辑一样，但是外部还是使用了方法名进行了区分

4.传参传接口(里氏替换原则)
通用功能，如果参数过多，可以使用接口的方式进行传参

5.实现类做业务逻辑判断，controller只做分支跳转
1）controller只接收数据，然后校验数据，校验合法性和准确性，比如说登录的controller，接收到用户名和密码，你要判断长度是否符合要求，密码解密出来。
2）有的必要的情况，创建一个对象，把数据补全，比如其他的一些简单的属性，创建时间啊修改时间啊，还有初始值什么的。
3）参数校验，Controller和Service层都需要，返回结果的聚合可在Controller中实现
4）业务相关逻辑放在Service中，使得Service接口能够成为一个完整的业务逻辑；
5）必要情况下可以在controller进行事务，这条看个人习惯和团队要求；
个人觉有些聚合的逻辑，在controller会更加明显，如微信小程序获取openId同时注册用户、初始化数据，如果在Service层全部完成，查看的时候就不太清晰

6.restful_api的规范
http://www.ruanyifeng.com/blog/2014/05/restful_api.html

7.java.lang.RuntimeException，该异常程序中可以不进行捕获和处理。

8.svn 注释模板

模板:

优化改善 #方法名:updateDelFlagById 修改DeleteMapping为PatchMapping，由于方法只是部分更新，修改方法的请求模式 #liuhao

其他描述

修正错误 #任务编号 任务标题
新增功能 #任务编号 任务标题
重构代码 #任务编号 任务标题
优化改善 #任务编号 任务标题
配置环境 #任务编号 任务标题
合并调试 #无任务编号 合并和调整内容
创建仓库 #无任务编号 创建内容

9.使用空行分割逻辑点、分割点使用//进行注释描述

10.**开发时，非关键点的日志可以不输出 **
1）非关键的数据使用debug输出
2）重要的数据使用info进行输出
3）已经抛出的异常的方法，可以不用在异常之前输出warn日志，warn用于内部的方法警告，如果需要返回给前端进行提示，方法抛出异常，全局进行捕获就可以了

11.复杂功先写脑图、流程图、功能步骤列表
开发过程中，按照顺序勾选功能步骤标记完成

12.方法禁止使用一个Json对象进行传参
无法里靠近方法调用之前使用了什么参数或者特殊处理

13.public方法放在类的上端
方便代码的查看，public方法在类的上端
private方法区域使用分割线标记