关于CodeReview(java)(转)

关于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

上一篇:旋转转盘选择Menu--第三方开源--CircleMenu


下一篇:拦截器原理