Code Review

目录

一、Review内容

1、基本规范

2、需要注意的地方：

3、什么是好的代码：

二、Review List

一、Review内容

1、基本规范

一块代码逻辑如果你站在一个陌生人的角度去看,第一遍看不懂的话,就需要添加注释了
一些不符合预期的情况，如一些未知异常（数据库的数据异常等），又或者不符合业务预期的特殊场景，都需要打印相关的日志
我们代码评审的时候，要注意参数是否都做了校验，如userId非空检查、金额范围检查、userName长度校验等等。一般我们在处理业务逻辑的时候，要遵循先检查、后处理的原则。
良好的异常处理可以确保代码的可靠性和可维护性。
代码评审的时候，关注一下，代码编写设计是否满足模块话，接口是否具有可扩展性
每个方法应该按照特定的顺序排列，例如：类变量、实例变量、构造函数、公共方法、私有方法等。

2、需要注意的地方：

大量重复代码（抽公用方法，设计模式）
方法参数过多（可封装成一个DTO对象）
方法过长（抽小函数）
判断条件太多（优化if…else）
不处理没用的代码（没用的import）
避免过度设计

3、什么是好的代码：

代码设计精良。
该功能对代码用户是有好处的。
任何 UI 变更都是合理的且看起来是好的。
其中任何并行编程都是安全的。
代码并不比它需要的复杂。
开发人员没有实现他们将来可能需要，但不知道他们现在是否需要的东西。
代码有适当的单元测试。
测试精心设计。
开发人员使用了清晰的名称。
注释清晰有用，且大多用来解释为什么而不是做什么。
代码有适当记录成文件（通常在 g3doc 中）。
代码符合我们的风格指南。

二、Review List

级别    检查项    如何执行
3    是否符合代码格式化标准    使用我们的格式化标准进行格式化
2    是否有多余的import项    不能有import xxx.*,不能有多余的import
2    是否定义了多余的field    定义了field，但是没有使用到的
2    是否定义了多余的本地变量    在方法中的本地变量，定义了却没有使用的
2    是否定义了多余的私有方法    定义了私有方法，但是没有地方调用
2    是否有可以重构的逻辑重复的代码    这个需要适当把握,同样的或者类似的逻辑有多次实现
2    方法／成员的public/private/static/final属性是否合理    
2    调用静态常量是否使用类／接口名 不应该使用实例名称去调用    
2    是否所有实现了java.io.Serializable接口的类都有serialVersionUID    
3    类／接口／变量／参数名，命名是否规范    尽量使用完整的单词，并且大小写合适，避免使用method1,method2这类没有意义的名字
3    所有的if,for,while块内容是否都用{}    
3    是否有功能复杂的语句    不要有太复杂的代码，代码应该简单、明了、直白
3    将url，文件路径等写死在程序里    使用配置或者URIBroker
3    将中文写在程序里    应该使用别的方案，根据具体情况使用ResourceBundle等
3    系统中使用到的非描述性字符串是否使用常量    比如状态值等
3    系统中使用到的数字是否使用常量    除了一些特殊的情况，比如for(int i=0;...
3    常量是否有详细的注释    常量的注释一定要清楚
2    程序中是否存在System.out,System.err及Throwable.printStackTrace()    这个比较严重的，有可能严重影响性能
1    系统中打开的流／文件／连接等是否保证能正常并及时关闭    
1    在输出日志时，低级别的输出一定要判断isXXEnabled info及一下级别    
1    在biz层中对DAO的访问是否可以简化    尽量进行少的访问次数，特别要禁止在循环中调用dao
1    在生产环境中输出大量调试日志    
1    注意使用对象的线程安全    
1    大规模的string组装    对象连接使用StringBuilder对象
1    递归方法的使用    尽量避免使用, 如果使用对深度进行控制.
1    本地线程对象是否导致memory leak ThreadLocal 对象必须是静态初始化    
1    异常处理    1. 必须合理的处理异常, 2, 处理完后回收资源.
1    系统中严格禁止硬转编码. GBK<===>8859_1    
1    是否编译过正则表达式,是否有大规模的表达式    会引起严重性能问题
1    是否有比较大规模使用String.indexof()    会引起严重性能问题
1    方法参数个数不能大于6个，即小于等于5个    相关性数据可封装成bean，把该bean作为参数
1    方法体长度不超过50行    提取、归纳逻辑，把大方法中的逻辑提取出若干个小方法
1    避免4层以上的if else嵌套    可使用逻辑阀门、策略模式、状态对象模式、command模式等