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
• 必要的验证码

水平权限

• 不用用户之间的不能相互操作

标准

• 代码整洁
• 可读性好
• 可维护性高
• 性能优

本文转自：http://iamzhongyong.iteye.com/blog/2149463