开发建议

1.控制器

1.1.统一返回值（统一返回值不是指所有接口返回同样的置，而是每一类（具体分类可以更具业务需要或者其他的方式）控制器只返会相同的JavaBean）。
避免方法签名的改动减少返工量；数据结构确定前后端数据处理减少沟通成本；返回结果一致代表可以使用aop处理。

1.2.无特殊需求都需要有返回值
在1.1的前提下，实现1.2则减少前端重复修改的成本；后期拓展性更强。

1.3.避免出现业务无关的入参，变量，校验等
无关入参（国际化参数，分页参数，token等），非当前业务变量等会干扰控制器处理逻辑，不论是编码实现时还是问题定位时都不利于业务逻辑的理解；参数校验和和其他公共数据校验会增加大量代码，不利于具体业务逻辑的整理，实现，定位和排错。业务无关的入参，变量等都可以通过ThreadLocal处理；校验则可以通过aop的方式统一处理。

1.4.出现json字符串入参或当参数超过三个时则需要定义Bean接收
json字符串的入参可读性极差，而且难以校验数据的正确性；参数过多的时候会影响调用者使用；定义Bean接收参数可以增加可读性，对调用者来说只需要关注参数Bean，而不需要关心顺序减少出错的可能性。

1.5.对于crud的控制器一定考虑权限和返回结果
crud的权限（示例仅供参考，具体业务有差异）新增，修改和删除提供个数据所有者，查询提供给所有用户；对于crud的返回（示例仅供参考，具体业务有差异）：新增返回ID，删除返回对象，修改返回ID和对象，查询返回列表或具体对象

1.6.定义统一的异常处理器，用于友好的向用户表达系统临时出现问题。

2.接口（一般是service和dao）

2.1.同1.1

2.2.禁止透传控制器返回值
如果接口将控制器的数据直接返回那么代表接口直接处理完成一个业务，这样违背分层（MVC）的初衷，也不利于接口被复用。

2.3.禁止出现json，map这类入参和返回值
json，map这类入参和返回值不论在哪里都缺乏可读性而且不能强制约束和校验必须约定一个规则（规则没有约束性），没有Bean有效和安全。

2.4.不允许出现Request，Response这些对象
原因是，控制器应该处理这类数据，如果接口有这些对象，那么接口实现类就必须是为特定的一个或一类请求提供的不利于复用和业务拆分。

2.5.日志允许出现在service和controller
主要的日志应该在service,controller不能作为主体，大量日志应该放在aop中

2.6.使用aop处理异常打印日志（接口和控制器都适用）
aop处理异常时分两类：已知和未知，分别打印日志，重点关注未知异常；aop打印日志可以收集请求时长等信息，便于后期找性能瓶颈。

2.7.定义业务异常（继承RuntimeException而不是Exception），减少异常捕获和空判断
减少异常的捕获，大部分异常都向外层抛有意义的自定义业务已常（如果异常时已知的时候）；减少空判断，在需要判空的时候抛异常（除了用户提交的数据），因为空判断会让系统执行正常（即使出错了）。出现异常之后的处理应该是通过某种途径告知开发者，记录日志，方便开发者及时知道问题并通过日志快速定位问题。

3.日志

日志的作用大部分是用于查找定位问题（bug）的，同时需要提供一定的量性数据支撑后面的性能分析。日志应该做到以下几点：

• 问题出现在那里（如果时分布式的则确定问题出现在那些机器设置某一台机器）
• 出现问题时正在处理那些数据（用户提交的数据，系统库里面的数据等）
• 在那一步出错了（查询DB出错，封装返回出错等）
• 重要方法执行时长
• 重要处理过程执行时长
• 性能消耗大的步骤执行时长

要做到上述三点则要求日志做到如下几点：

• 新增，修改和删除必须有日志
• 出现分支打日志，并且记录一些重要数据（例如：决定分支走向的数据等）
• 重要方法一定要通过aop打上日志记录处理过程中的重要步骤以及处理时长
• 重要的处理过程也需要打上日志记录每个过程产生的数据并处理时长
• 已知的可能导致性能问题的处理过程需要打上日志

4.工具类

4.1.具体业务代码减少第三方类库的使用，第三方类库尽量使用自定义工具类实现
使用工具类封装第三方类库可以很方便的迁移，防止第三方类库的变更升级导致业务代码的大量重构

4.2.工具类尽量使用父类型
例如：操作ArrayList<E>时工具类入参应该是List或Collection。这样工具类更加通用

4.3.尽量使用重载
减少方法的记忆；实现代码复用（嵌套调用）