开发建议

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.尽可能使用重载减小方法的记忆；实现代码复用（嵌套调用）