Java Code Review清单

标签: 基础技术 Code Review | 发表时间:2014-07-28 00:00 | 作者:陈 晓舜
出处:http://www.importnew.com

整洁的代码

清单项目 分类
使用可以表达实际意图(Intention-Revealing)的名称 有意义的名称
每一个概念只用一个词 有意义的名称
使用方案/问题领域名称 有意义的名称
类应该是比较小的!
函数应该是比较小的! 函数
只做一件事 函数
DRY(Don’t Repeat Yourself)原则,(拒绝重复) 函数
用代码来解释自己的做法(译者注:即代码注释) 注释
确定应用了代码格式化 格式
使用异常而不是返回码 异常
不要返回Null 异常

*参考自: http://techbus.safaribooksonline.com/book/software-engineering-and-development/agile-development/9780136083238

安全

清单项目 分类
如果不用于继承,使类为final 基础
避免重复代码 基础
权限限制:程序应该运行在保证功能正常的最小权限模式下。 基础
最小化类和成员的可访问性 基础
注释出安全相关的信息 基础
系统的输入必须检查是否有效和在允许范围内 拒绝服务(Denial of Service)
避免对于一些不寻常行为的过分日志 拒绝服务(Denial of Service)
在任何情况下都释放资源(流,连接等等) 拒绝服务(Denial of Service)
从异常中清除敏感信息(暴露文件路径,系统内部相关,配置)P 私密信息(Confidential Information)
不要把高度敏感的信息写到日志 私密信息(Confidential Information)
考虑把高度敏感的信息在使用后从内存中清除 私密信息(Confidential Information)
限制包,类,接口,方法和域的可访问性 可访问性的扩展(Accessibility Extensibility)
限制类和方法的可扩展性(通过使它为final) 可访问性的扩展(Accessibility Extensibility)
检验输入(有效的数据,大小,范围,边界情况等等) 输入检验(Input Validation)
把从不可信对象得到的输出作为输入来检验 输入检验(Input Validation)
为native方法定义包装类(而不是定义native方法为pulibc) 输入检验(Input Validation)
把从不可信对象得到的输出作为输入来对待 可变性
使public static域为final(避免调用方(caller)修改它的值) 可变性
避免暴露敏感类的构造函数 对象构造
避免安全敏感类的序列化 序列化反序列化(Serialization Deserialization)
通过序列化来保护敏感数据 序列化反序列化(Serialization Deserialization)
小心地缓存潜在的特权操作结果 序列化反序列化(Serialization Deserialization)
只有在需要的时候才使用JNI 访问限制

*参考自: http://www.oracle.com/technetwork/java/seccodeguide-139067.html

性能

清单项目 分类
避免过分的同步 并发
保持同步区域比较小 并发
知道string连接的性能情况 综合编程
避免创建不需要的对象 创建和销毁对象

*参考自: http://techbus.safaribooksonline.com/book/programming/java/9780137150021

综合(译者注:原文中的作者把checklist和category对应的列搞错了,译文中已修正)

清单项目 分类
对可以恢复的情况使用已受检异常(checked exceptions),对于程序错误使用运行时异常(runtime exceptions) 异常
更多地使用标准异常 异常
不要忽略异常 异常
检查参数的有效性 方法
返回空数组或集合,而不是null 方法
最小化类和成员的可访问性 类和接口
在pulibc类中,使用访问器方法(accessor methods)(译者注:访问器方法即我们平常用的get/set方法)而不是public域 类和接口
最小化本地变量的范围 综合编程
通过接口引用对象 综合编程
遵循广泛接受的命名规则 综合编程
避免使用finalizer 创建和销毁对象
当你重写equals时总是重写hashCode 综合编程
总是重写toString 综合编程
使用枚举来代替int常量 枚举和注解(Annotations)
使用标记接口(marker interface)(译者注:标记接口是一种没有任何行为的接口,实现它只是为了让实现类属于某种类型,如JDK中的Serializable,Cloneable等)来定义类型 枚举和注解(Annotations)
对共享可变的数据使用同步访问 并发
使用executors而不是task和thread 并发
注释中描述线程安全情况 并发
存在有效的JUnit/JBehave测试用例 测试

*参考自: http://techbus.safaribooksonline.com/book/programming/java/9780137150021

静态代码分析

清单项目 分类
查看静态代码分析器的报告来进行类的添加和修改 静态代码分析

可能感兴趣的文章

相关 [java code review] 推荐:

Java Code Review清单

- - ImportNew
使用可以表达实际意图(Intention-Revealing)的名称. DRY(Don’t Repeat Yourself)原则,(拒绝重复). 用代码来解释自己的做法(译者注:即代码注释). *参考自: http://techbus.safaribooksonline.com/book/software-engineering-and-development/agile-development/9780136083238.

聊聊Code Review

- - 梦想风暴
hopesfish评论《 那一点的调用》时,问了一个关于Code Review的问题:. 想请教一下,TW的筒子是如何做code reivew或者鼓励客户做code review的. 我在翻阅博主的帖子的时候,似乎对这块没有特别强调,而是更多偏重于TDD,我觉得TDD的问题是一碰到没有责任心的程序猿,就很容易流于形式了.

我的code review规则

- vento - 我的宝贝孙秀楠 ﹣C++, Lua, 大连,程序员
1) 是否有语法错误,编译错误,编译警告. 做法:下载最新代码,将编译警告级别提升到最高,检查output信息. 2)是否符合需求,完成requirement文档要求的内容,不能多,也不能少. 注意:即使发现有问题代码,如果与需求关联不大,不要涉及. 应该让每次enhancement和bug fix最简洁,牵涉范围最小,影响到组件最少.

Code Review那些事儿

- - 非技术 - ITeye博客
       曾经有一段 垃圾代码放在我的面前,我没有拒绝,等我真正开始接手的时候我才后悔莫及,程序员最痛苦的事莫过于此. ---------改编于周星星的经典台词.       虽然有点夸张,但编码界确实大大存在这种情况,每当接手别人的代码,都有一种想重新写一遍的感觉,等到别人再来接手你的代码时,同样的感觉.

[原]强制 code review:reviewboard+svn 的方案

- - 赖勇浩的编程私伙局
赖勇浩( http://laiyonghao.com). 我们团队在开发《天下盛境》项目的时候,制定和执行了比较好的 code review 策略,总结下来有几个优点:一是代码风格可控,代码质量有一定提升;二是新员工入职后能够得到更多人的指导,成长非常快;三是小 bug 频出的情况比我做《天》之前的项目少了至少一个数量组.

代码审查(Code Review)清单

- - 博客 - 伯乐在线
代码审查可以帮助提高代码质量,避免由于代码习惯而造成的 bug. 下面列出的这些要点因该可以作为大部分代码审查的指导,如果是 Java 应用的话,这些建议应该被视作最佳实践. Javadoc 应该在每一个类和方法中添加. 如果是修复某个 bug,应该添加 bug ID. 走捷径的方法或者复杂的逻辑要有解释.

从Code Review 谈如何做技术

- - 酷 壳 - CoolShell.cn
(这篇文章缘由我的微博,我想多说一些,有些杂乱,想到哪写到哪). 这两天,在微博上表达了一下Code Review的重要性. 因为翻看了阿里内部的Review Board上的记录,从上面发现Code Review做得好的是一些比较偏技术的团队,而偏业务的技术团队基本上没有看到Code Review的记录.

我们该如何做好Code Review?

- - SegmentFault 最新的文章
我们该如何做好Code Review?. 午后的阳光,静静地照在你的脸上. 这时候配上一杯82年的java,脑子一片灵光闪过,呃......上午刚写完需求,下午好像没什么事了,不如看看自己写的代码. 至此,一场Code Review也就拉开序幕了. Code Review,即代码审查,是指对计算机源代码系统化地审查,常用软件同行评审的方式进行,其目的是在找出及修正在软件开发初期未发现的错误,提升软件质量及开发者的技术.

测试技术中CODE REVIEW的重要性

- - CSDN博客推荐文章
        [近期关注App自动化测试,欢迎交流,本博客文章版权归作者所有,转载请联系]     .         最近有网上的朋友向我咨询作为测试员是否应该跳槽,   首先我觉得应该向大家介绍一下什么是测试工程师,  什么是测试员,   在国内的一些中型企业并没有特别的指明.   这里测试工程师主要指测试开发工程师, 主要包括两类,  其一是测试软件开发的工程师,  其二是自动化测试脚本开发和维护的工程师,   而测试员主要指单纯编写/管理测试用例,  或是手工测试人员, 一些国内的大中型网络视频公司仍然在用纯手工测试,我感觉到很汗颜.