《Java开发手册》-部分编码规范分享

0. 前言

本文来自《阿里巴巴Java开发手册》，以下内容均根据自己偏好摘抄、总结、分享。

---

1. 编程规约

• 包名单数，类名复数。例如：com.tao.util.JsonUtils.java
• 不要使用一个类来维护所有的常量，要根据功能进行分类。例如：
  • 缓存常量类：CacheConsts
  • 配置常量类：ConfigConsts
• Object的equals容易抛出空指针，推荐使用 java.util.Objects#equals：

  public static boolean equals(Object a, Object b) {
      return (a == b) || (a != null && a.equals(b));
  }
  

• String#split 会丢弃后面的空白。例如："1,2,,," => ["1","2"]
• Collections#emptyList()/singletonList() 都是不可变对象，不能添加删除元素。
• ArrayList 中 subList 返回的内部类 SubList，并不是 ArrayList，而是 ArrayList 的一个视图，操作 subList，ArrayList 数据也会跟着变化。
• 如果 if 语句条件复杂，可以复制给一个变量。
• 批量操作接口入参需要进行保护，超过多少条不进行处理。
• 参数校验：
  • 很少进行执行的，参数校验也不会耗费多少性能。
  • 执行时间开销大的，执行时间长，尽可能保证别执行一半出错了。
  • 需要稳定性高的，如银行系统，必须进行参数校验，不稳定，损失的都是真金白银。
  • 对外提供的开放接口，不知道别人会给你传过来什么数据，脏数据不处理，你的系统就成垃圾场了。
  • 权限敏感接口，参数校验失败，出现删库跑路。

---

2. 异常日志

• 细粒度处理异常，不要 catch 一大段（catch 一大段，你很难知道什么地方抛出了异常，从而很难进行正确的异常处理）。
• 可以使用 warn 记录用户输入参数的错误情况，如非必要不要再此场景打出 error 级别，error 只记录系统逻辑出错、异常等重要的错误信息。（比如用户数据参数错误，你给了"xxx 参数不正确"的返回，此场景不需要打 error，用户能根据错误提示进行修正。）

---

3. 单元测试

• 对数据库的操作应该设置回滚操作，单元测试不应该污染数据库，且单元测试的数据应该使用单元测试的标识，方便区分。

---

4. 安全规约

• 用户请求传入的任何参数必须做有效的验证：
  • pageSize 过大容易导致内存溢出。
  • 恶意使用 orderBy 导致慢查询。
  • 短信、邮件、电话、下单、支付等场景必须实现正确的防重放机制（公司的短信都是先发送到MQ，然后消费者去消费，某次消费者逻辑出现异常，导致消息被重复消费好几遍，还好消费逻辑有校验是否发送过短信，否则一个用户会发送好多遍短信）。

---

5. MYSQL

建表规约

• 表达是否概念的字段必须使用 is_xxx 的方式，类型为 unsigned tinyint（1是0否）（is_xxx 仁者见仁智者见智）。
• 表名不使用复数的形式。
• 单表超过500万才建议分库分表。

索引规约

• 业务上具有唯一特性，即使多个字段，也必须建成唯一索引。
• 页面搜索禁止全模糊或左模糊（因为大多数情况，这俩不走索引）。
• 建组合索引，区分度高的放左边。

语句

• count(*) 统计null行，count(列名) 不统计null行。
• 使用 ISNULL 判断是不是null值。
• 分页逻辑，如果 count=0 直接返回，避免执行后面的分页语句。
• in 后面的集合元素的个数，最好控制在1000内。
• 不要写大而全的数据更新接口。
• @Transactionanl 事务不要滥用，事务会影响数据库的QPS。使用事务要考虑，缓存回滚、消息补偿，统计修正等。

---

6. 工程结构

• DO 与数据库表一一对应。
• DTO：service向外传输的对象。
• BO：由service输出的封装业务逻辑的对象。
• Query参数超过2个，需要进行封装。
• 二方库：
  • JSON：fastjson
  • MD5：commons-codec
  • 数据操作：ArraysUtils
  • 集合操作：CollectionsUtils

7. 总结

以上为看书总结自认为有用的部分，推荐阅读原书。