Java Code Review 指南

Java代码俯身指南，主要为Java开发人员提供代码复审参考，快捷有效提出修改意见。

目的

• 发现代码错误：一个人写的代码可能会有一些思想和设计盲点，多个人尽早的发现BUG。
• 统一代码风格：统一的代码风格，可以提高代码的可读性和可维护性。
• 优化代码结构：比较复杂的业务处理逻辑，多个人同时思考，可以想出较为优秀的解决方案。
• 共同成长：相互之间分享编码经验，可以共同进步。避免发生类似错误。

原则

• 统一性：看上去像一个人写的
• 可读性：提供代码的可读性
• 可维护性：降低其他人的维护成本

时间

审查的时间点顺序如下

1. 接口定义完成时，需要进行第一轮审查，此审查最重要。
2. 数据库初步设计完成，在数据库完成时，需要进行审查。
3. 接口开发完成，静态语法检测完成，提测之前，需要进行审查。

心态

1. 聆听：先把别人要讲的话听完。可以先记录当前的疑问。
2. 开放：有疑问的地方一定要提出，不仅可以完善当前程序的逻辑，也可以完善自己的逻辑。
3. 公正：把个人的成果当作团队的成果，把团队的成果也当作个人的成果。对待代码，不要进行人身攻击。
4. 统一：当不同的方法都可以实现程序逻辑时，应该以统一性、可读性、可维护性为准则。

人员

以下人员必须参与代码审核。

1. 结对编程的另一个人。
2. 项目的具体负责人。
3. 一名有经验的开发人员。

其他人员可以选择自愿参与。

Java Review

通用

• 代码是否符合需求，是否可以输出正常结果。
• 是否有明确错误。
• 不要返会null数组/集合。使用Collection.emptyList()等静态方法返回空集合。
• 不要有反思维的系统设计。使用大多数人容易理解的逻辑处理问题。如果有通用的算法模型除外。
• 不要有明显的性能问题。比如大量的数据库交互、文件交互、RPC接口交互。
• 类注释。描述该类的功能和接口范围。
• 方法注释。所有对外提供的接口，必须进行详细的注解说明，说明返回的数据类型和特殊情况处理。
• 方法内部注释。当一个方法体超过20行时，需要对具体的业务，作说明解释，而不仅仅是实现作解释。
• 理解本次更改的功能设计。进行code review的人必须完全理解每一个接口的具体功能。
• 理解本次更改的实现细节。理解开发者的实现具体想法。
• 不可以大量拷贝代码，又不做细节调整。不需要的代码必须都删除。
• 使用枚举定义的标识分组，而不是使用int/long定义常量标识。比如订单的所有状态、用户状态等。
• static变量必须要携带final修饰符。所有的静态变量为了线程安全必须被final标注。如过允许多线程变更静态变量，应当提供静态方法进行修改。
• 在任何情况下都要释放资源，io.close\pool.return\connection.close
• 日志记录。在必要的接口开始和结束位置记录参数日志。日志记录方法详见Java使用slf4j输出日志。
• 避免过度多日志记录。不要记录太多无用的日志。
• 对外接口使用可处理的返回码，而不是抛出Exception。
• 代码一定要格式化。
• 不允许修改原有API接口的参数。
• 避免循环引用。
• 避免内存泄漏。不需要的类，及时清空自己的属性引用。
• 调用第三方的接口和第三方类方法，是否捕获了所有异常。
• 对内提供的RPC接口统一使用Response类和RespCode响应码。
• 和业务结合的算法，要明确注释清楚。
• 每个变量必须有实际意义，不可以随便使用 i、j、temp等通用变量（经典的for i遍历可以例外）。

入参

• 对所有的入参进行有效验证。
• 对入参的边界值进行校验。
• 对入参进行注释。

配置文件

1. 不准引用其他所有包中的属性配置文件（xx.properties)。
2. 配置文件需要统一放在最终项目启动包中。
3. 不准引用非本项目的配置文件，包括Spring的Bean声明文件、Log的配置文件等。

SQL Review

命名

1. 表名和字段名都必须使用小写，单次之间使用下划线（ _ ）作分割。如user_center、patient_name、area_id
2. 索引命名。
   • 普通索引使用idx_作为前缀，后面根据索引顺序用下划线（ _ ）连接各个字段名，字段名使用驼峰格式。如idx_patientName_areaId等。
   • 唯一索引使用uni_作为前缀，后面根据索引顺序用下划线（ _ ）连接各个字段名，字段名使用驼峰格式。如uni_patientName_areaId等。

数据类型

1. 表引擎使用InnoDB，编码使用utf8。特定情况例外，需要与组内讨论和DBA确认。
2. 每张表必须有唯一主键。建议使用自增主键。
3. 每张表建议包含创建时间（字段名：gmt_created，类型：datetime)、修改时间（字段名：gmt_modified，类型：datetime)。
4. 如果是后台用到的数据表，也可以考虑加入创建员工（字段名：staff_created，类型：long)，修改员工（字段名：staff_modified，类型：long)
5. 日期类型（yyyy-MM-dd）使用date类型，日期时间类型（yyyy-MM-dd HH:mm:ss）使用datetime。
6. 自增主键建议使用bigint(20)。枚举类型除外，可以适当考虑使用int(10)。
7. 在字段中尽量不要使用tinyint和smallint。
8. 经常使用的查询组合可以考虑联合索引。
9. 如果字段包含特殊字符，比如emoji表情等，需使用utf8mb4字符集。用户可输出的地方，都应该对此进行印证。

SQL语句

1. 所有的查询都必须走索引。
2. 每一条使用join语句必须由DBA和主管确认。

安全

1. 代码应确保多线程访问的数据一致性。

提交

提交原则

• 单一提交：一个commit变更应该以一个功能、一种类型的修改为主。多次提交可以保证每次修改可以正确记录和错误回滚。
  • 以下分类最好不要同时提交。修复BUG、新功能、修改原接口
  • 在定义完一系列接口、修复完一个BUG等情况即可提交。
• 完整性：一个commit提交后，程序应该仍然可以正常运行。
  • 不要提交过于小且没有完整意义的commit。

提交说明

提交的message英石解释两个方面，做了什么和为什么要做。 提交标题总结本次提交都做了什么，提交细则详细描述为什么要这么做。

不推荐

修复了一个BUG

新增了两个接口

修改了两个接口

推荐

1.修复用户密码登录接口BUG。用户登录名，需要大小写敏感。之前未做大小写敏感处理。

1.新增用户微信第三方登录接口。
2.用户绑定微信第三方登录。
支持用户微信第三方登录和绑定。

1.修改用户注册接口
用户注册的时候可以传递邀请码。