之前和其他团队进行合作。由于不同团队的编写水平不一致，导致很多地方需要重新架构，其实大部分难运维的原因是不规范，所以在修改的过程中，觉得还是把自己的代码习惯整理起来，便于以后进行查看，当然作为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 进行处理
如图内部处理逻辑一样，但是外部还是使用了方法名进行了区分
image.png

image.png

4.传参传接口
通用功能，如果参数过多，或者参数动态获取，可以考虑使用接口的方式进行传参

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

image.png

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

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

8.svn 注释模板
1） svn模板:
优化改善 #方法名:updateDelFlagById 修改DeleteMapping为PatchMapping，由于方法只是部分更新，修改方法的请求模式 #liuhao

其他描述

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

2） 提交SVN,必须比较修改的地方，避免出现硬编码，测试代码上传至正式库

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

image.png

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

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

12.方法禁止使用一个Json对象进行传参
无法了解进方法调用之前使用了什么参数或者特殊处理；可读性很差
image.png

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

14.入参空指针判断
1）调用其他方法的结果，作为下个方法的入参时，如果涉及到get、set、put等值操作方法，必须判断其是否为空指针
2）调用其他接口时，如果其接口实现中，返回了null结果，必须进行空指针判断处理
3) 实现list返参的接口时，必须新建一个list对象，即操作结果为空时，返回size为0的空集合；避免调用时，需要对判断返参list是否为空的判断的操作
4）无论内部方法还是外部接口调用，均对其结果是否做过NULL值处理，一致认为不可信
5) private内部方法可以不做空指针的判断

15.入参顺序
个人习惯是按照从轻到重的顺序，添加方法入参
如:基本数据类<基本数据的包装类<对象<list集合<map
image.png
或者按照入参的变动程度顺序,容易变动的参数优先

16.返参类型
返参禁止使用很宽泛的类型，如图在实际项目中遇到的返参使用了map,而且还定义了value为Object
image.png

17.equals
1）常量或确定有值的对象来调用equals(手册要求)

" test " .equals(object)

2）遇到存在一组相反状态值，尽量使用目标值的相反值调用equals
在项目遇到，需要判断当前记录是否完成计费，我们定义了"0"状态为未计费，"1"状态为已计费

Constant.UN_PAID.equals(records.getPayStatus());

由于同事在初始化数据时，并没给payStatu赋值为"0",查询的结果中payStatus的值为空,按照业务要求，此时为未计费,所以为了避免背锅，使用了其相反的状态调用equals

!Constant.ALREADY_PAID.equals(records.getPayStatus());

18.流操作
1）流必须关闭!!流必须关闭!!流必须关闭!!
之前遇到一个同事需要删除历史文件，调用file的delete方法，一直返回fasle,最后发现其在方法里面新建一个流对象传入，并没有把流关闭，导致文件一直被JVM占用着
2）流关闭必须finally语句中关闭,不可以在代码块中直接调用close方法
java7之后，可以使用try-with-resources语句来释放java流对象，从而避免了try-catch-finally语句的繁琐

19.异常上抛
1）接口中需要提醒业务自己处理的异常，必须在接口上明显标记

2）调用请求URL类方法，必须上抛异常
腐败代码:
image.png
这是我们一个同事底层提供公共对外接口调用方法，一开始我想捕获异常，提醒前端接口出错警告，最后发现当出现500状态时，报空指针异常，并且try-catch无法捕获异常，所以整理出该条规范
3)多个异常需要上抛，超过三个左右，就可以考虑自定义异常类型了，如图，可以考虑祭天

image.png

20.数据库
1）批量修改数据库之前，先使用select查询出需要更新的语句，再使用查询添加作为更新update的条件。前同事，由于更新前没做筛选，导致加班连夜根据数据库日志文件还原数据