java中的codereview
关于codereview，在平时的开发中，经常忽略的环节，参照目前介绍写好代码的几本书和之前掉进的坑，做了一个总结，分享出来。
为什么要做
- 通过review规避一些代码层面的问题
- 提升可读性，方便后续扩展和维护
- double check 确保代码质量
检查列表
注释
- 写有意义的注释
- DO属性上，名字无法识别业务含义的，加注释
- service接口和manager接口，注明方法的说明
- 代码块中的复杂逻辑，添加注释
风格
- 域名不要写死
- 不同环境下差异的，注意使用配置项
日志
- 合理分配日志级别，warn和error要分开
- 日志中，异常信息要记录，第一个参数简短说明，第二个异常信息
- 日志异常注意把相关的参数信息记录下来，例如userId等
- 异常抛日志的情况下，主要不要引入二次异常
- 配置参数
线程安全
- 需要被多个线程访问的对象是否线程安全，检查有无通过同步方法保护
- 在保证线程安全的同时，要注意避免过度使用同步，导致性能降低
- 不用使用Java原生的线程处理方法，推荐使用JUC框架中的类
- 根据场景选择不用的线程池来实现，会用简化版Executors，理解处理过程
异常处理
- 不要直接e.printStackTrace，用Logger记录下来
- 异常捕获之后，要做响应的处理，返回错误提示或者记录日志，切忌啥都不做
- 当前程序中能够处理的异常，捕获即可，无法处理的，抛出
- 异常只为异常服务，不要掺杂业务逻辑到异常中
性能
- 避免多重的RPC或者网络IO的循环，尽量批处理
- 避免无穷循环，要有终止条件判断
- 不要主动进行垃圾回收，代码中不要有System.gc()
- String的split方法不要用，用开源包中的StringUtil工具类
- 字符串的拼接，使用StringBuilder和StringBuffer
代码逻辑
- 不要在finally中return（try中的返回值，屏蔽异常）
- volatile不具有原子性，划分好synchronized的粒度问题
- 推荐使用Guava作为工具处理类
- 推荐joda来处理时间，然后SimpleDateFormat是非线程安全的
- 单个方法超过50行，要做抽取，否则无法保证可读性
- 方法入参超过5个，抽取到QueryTO中进行处理
- for或if的层级嵌套，不要超过4层
- if的逻辑判断中，多个||和&&的组合，注意拆分处理
- case语句后面，需要加break
- if后面，记得写大括号
- 文件资源，访问后，记得close掉
- 排序优先使用Comparator，一个类的扩展排序工具
- 使用addAll、retainAll、removeAll优雅实现并集、交集、差集
- List的remove，使用迭代器来进行删除
事务处理
- 多表同时更新操作，需要事务包裹，并验证过
- 批量插入，使用iBatis的batchInsert特性，需要在事务下才生效,可以通过wireshark查看网络情况
- 分布式场景下，可以使用消息中间件来保证最终一致性
- 声明式事务注解标签，尽量在manager层搞掉，不要搞到service层或者web层
- 一些可能出现重复处理的方法，记得做幂等操作
重复代码
- don’t repeat yourself
- 同样的业务逻辑处理，不要有两份代码
安全问题
XSS
- cookie设置httponly属性
- jsonp输入输出检查
CSRF
- 服务端增加CSRF校验，增加token
- 必要的验证码
水平权限
- 不用用户之间的不能相互操作
标准
- 代码整洁
- 可读性好
- 可维护性高
- 性能优
