BaiFan

本文可转载演绎，但需要注明原作者和本文链接。

By

文章目录
  1. 1. 目的
  2. 2. 原则
  3. 3. 时间
  4. 4. 心态
  5. 5. 人员
  6. 6. Java Review
    1. 6.1. 通用
    2. 6.2. 入参
  7. 7. 配置文件
  8. 8. SQL Review
    1. 8.1. 命名
    2. 8.2. 数据类型
    3. 8.3. SQL语句
  9. 9. 安全
  10. 10. 提交
    1. 10.1. 提交原则
    2. 10.2. 提交说明

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英石解释两个方面，做了什么和为什么要做。
提交标题总结本次提交都做了什么，提交细则详细描述为什么要这么做。

不推荐

1
修复了一个BUG
1
新增了两个接口
1
修改了两个接口

推荐

1
1.修复用户密码登录接口BUG。用户登录名，需要大小写敏感。之前未做大小写敏感处理。
1
2
3
1.新增用户微信第三方登录接口。
2.用户绑定微信第三方登录。
支持用户微信第三方登录和绑定。
1
2
1.修改用户注册接口
用户注册的时候可以传递邀请码。
Quality
JavaStyle
文章目录
  1. 1. 目的
  2. 2. 原则
  3. 3. 时间
  4. 4. 心态
  5. 5. 人员
  6. 6. Java Review
    1. 6.1. 通用
    2. 6.2. 入参
  7. 7. 配置文件
  8. 8. SQL Review
    1. 8.1. 命名
    2. 8.2. 数据类型
    3. 8.3. SQL语句
  9. 9. 安全
  10. 10. 提交
    1. 10.1. 提交原则
    2. 10.2. 提交说明