Java Code Review清单
- - ImportNew使用可以表达实际意图(Intention-Revealing)的名称. DRY(Don’t Repeat Yourself)原则，(拒绝重复). 用代码来解释自己的做法(译者注：即代码注释). *参考自: http://techbus.safaribooksonline.com/book/software-engineering-and-development/agile-development/9780136083238.
Java Code Review清单
标签：
基础技术
Code
Review
| 发表时间：2014-07-28 08:00 | 作者：陈 晓舜
出处：http://www.importnew.com
整洁的代码
| 清单项目 | 分类 |
|---|---|
| 使用可以表达实际意图(Intention-Revealing)的名称 | 有意义的名称 |
| 每一个概念只用一个词 | 有意义的名称 |
| 使用方案/问题领域名称 | 有意义的名称 |
| 类应该是比较小的! | 类 |
| 函数应该是比较小的! | 函数 |
| 只做一件事 | 函数 |
| DRY(Don’t Repeat Yourself)原则，(拒绝重复) | 函数 |
| 用代码来解释自己的做法(译者注：即代码注释) | 注释 |
| 确定应用了代码格式化 | 格式 |
| 使用异常而不是返回码 | 异常 |
| 不要返回Null | 异常 |
安全
| 清单项目 | 分类 |
|---|---|
| 如果不用于继承，使类为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] 推荐：
聊聊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）清单
- - 博客 - 伯乐在线代码审查可以帮助提高代码质量，避免由于代码习惯而造成的 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
- - IT瘾-dev一、Code Review的好处. 想要做好Code Review，必须让参与的工程师充分认识到Code Review的好处. 无论是高手云集的架构师团队，还是以CURD为主的业务开发团队，大家的技术能力、经验都是有差异的. 通过Code Review，对于同样的功能实现，有经验的工程师可以给经验尚浅的工程师提供合理的优化建议.
测试技术中CODE REVIEW的重要性
- - CSDN博客推荐文章 [近期关注App自动化测试，欢迎交流，本博客文章版权归作者所有，转载请联系] . 最近有网上的朋友向我咨询作为测试员是否应该跳槽, 首先我觉得应该向大家介绍一下什么是测试工程师, 什么是测试员, 在国内的一些中型企业并没有特别的指明. 这里测试工程师主要指测试开发工程师, 主要包括两类, 其一是测试软件开发的工程师, 其二是自动化测试脚本开发和维护的工程师, 而测试员主要指单纯编写/管理测试用例, 或是手工测试人员, 一些国内的大中型网络视频公司仍然在用纯手工测试，我感觉到很汗颜.