方法的传参

除了一些通用的方法外，避免使用map，json等键值对形式的类型作为传入参数

尽量不要使用String类型作为入参，如果需要，请做好判断（大小写，空格，长度限制…）

三个以内参数可以直接列出

接收前端的表单请求统一用VO进行接收（vo可继承）

对于数组类型的返回值，没有数据时返回0长度的数组，不要返回null（给调用者带来空指针隐患）

JavaBean，POJO，VO，DTO的区别和联系

vo是主要体现在视图的对象，将一个页面属性封装成一个对象，用vo在控制层和视图层进行传输

即POJO是一个简单的普通的Java对象，它不包含业务逻辑或持久逻辑等，但不是JavaBean、EntityBean等，不具有任何特殊角色和不继承或不实现任何其它Java框架的类或接口。

POJO对象有时也被称为Data对象，大量应用于表现现实中的对象。

一个POJO持久化以后就是PO。

直接用它传递、传递过程中就是DTO

直接用来对应表示层就是VO

直接用它传递、传递过程中就是DTO（将需要操作，类或方法之间传输的属性单独封装成一个）

BO(business object) 业务对象

从业务模型的角度看,见UML元件领域模型中的领域对象。封装业务逻辑的java对象,通过调用DAO方法,结合PO,VO进行业务操作。  

PO(persistant object) 持久对象

在o/r映射的时候出现的概念，如果没有o/r映射，没有这个概念存在了。通常对应数据模型(数据库),本身还有部分业务逻辑的处理。可以看成是与数据库中的表相映射的java对象。最简单的PO就是对应数据库中某个表中的一条记录，多个记录可以用PO的集合。PO中应该不包含任何对数据库的操作。

应对传入的参数进行有效性检查

判断是否有记录时使用select 1 from提高效率https://www.cnblogs.com/baili-luoyun/p/11168545.html（结果栏都是1，行列数一样，不用查字典表，提高效率）

dao层只返回数据库的查询结果，service返回我们需要的类型

RpcService统一返回RpcRespDTO<T>（对放回的结果进行了封装，里面还有状态码，错误信息等）

如果一个方法超过80行或者处理的业务较多的时候，因对其进行相应的抽取，让方法保持简单

get、set方法里面不写处理逻辑，推荐使用lombok编写java bean

接口不应该用来导出常量

如果其他类型更适合，请避免使用float和double

服务端捕获DataAccessException，方式dao层错误，避免把数据库表字段相关信息暴露给前端

对于spring mvc的对外接口，通过swagger编写接口注释，并生成接口文档，增强可读性，生成相关文档（https://www.jianshu.com/p/a0caf58b3653）

RPC接口，需要在接口中详细编写注释（接口作用，入参说明，出参说明）

打印信息使用log

对于特性分支，直接使用分支名称标识jar包版本号

<version>feature-redpacket-SNAPSHOT</version>

对于每周发版分支，通过日期标识jar包版本，作为后

<version>20161120-RELEASE</version>

对外jar包每次更新马上更新到maven库

需要补充的块使用TODO

代码嵌套不要超过三层以上（合并条件，提取到独立方法，利用 return 以省略if后面的else）

能用局部变量的，不要使用实例变量，能用实例变量的，不要使用类变量（减少被误用，线程更安全）

尽量不要用参数来带回方法运算结果（此方法仅仅ruturn计算结果就行了，再方法外set进去），保证参数不为空。

public void calculate(Order order) {

 int result = 0;

 //do lots of computing and store it in the result

 order.setResult(result);

}

涉及所有浮点数的运算，一律用BigDecimal运算来保证准确度。系统框架已提供封装后的方法。（https://blog.csdn.net/haiyinshushe/article/details/82721234 ）

关闭资源在finally里面

避免使用不易理解的数字，用有意义的标识来替代。不应直接使用数字，必须用有意义的静态变量来代替（man=1，woman=2）

通用功能提取成方法

异常捕捉后，如果不对该异常进行处理，则应该记录日志或者ex.printStackTrade();

用括号明确计算步骤，避免使用默认优先级