开发规范

异常日志

异常处理

防止 NPE，是程序员的基本修养，注意 NPE 产生的场景

1）返回类型为基本数据类型，return 包装数据类型的对象时，自动拆箱有可能产生 NPE。<br> 反例：public int f() { return Integer 对象}， 如果为 null，自动解箱抛 NPE。 2） 数据库的查询结果可能为 null。 3） 集合里的元素即使 isNotEmpty，取出的数据元素也可能为 null。 4） 远程调用返回对象时，一律要求进行空指针判断，防止 NPE。 5） 对于 Session 中获取的数据，建议 NPE 检查，避免空指针。6） 级联调用 obj.getA().getB().getC()；一连串调用，易产生 NPE。正例：使用 JDK8 的 Optional 类来防止 NPE 问题。

日志规约

安全规约

工程结构

应用分层

分层领域模型规约

1. DO（Data Object）：此对象与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。  2. DTO（Data Transfer Object）：数据传输对象，Service 或 Manager 向外传输的对象。  3. BO（Business Object）：业务对象，由 Service 层输出的封装业务逻辑的对象。  4. AO（Application Object）：应用对象，在 Web 层与 Service 层之间抽象的复用对象模型，极为贴近展示层，复用度不高。  5. VO（View Object）：显示层对象，通常是 Web 向模板渲染引擎层传输的对象。  6.Query：数据查询对象，各层接收上层的查询请求。注意超过 2 个参数的查询封装，禁止使用 Map 类来传输。

二方库依赖

服务器

开发规范

编程规约

命名风格

变量驼峰命名

避免java关键字

抽象类命名使用 Abstract 或 Base 开头；异常类命名使用 Exception 结尾；测试类命名以它要测试的类的名称开始，以 Test 结尾。

如果模块、接口、类、方法使用了设计模式，在命名时需体现出具体模式。说明：将设计模式体现在名字中，有利于阅读者快速理解架构设计理念。

常量定义

不可变常量定义需要加final关键字

全部大写

不允许任何魔法值

如果变量值仅在一个固定范围内变化用 enum 类型来定义。

代码格式

单个方法的总行数不超过 80 行

不同逻辑、不同语义、不同业务的代码之间插入一个空行分隔开来以提升可读性。

OOP规约

Object 的 equals 方法容易抛空指针异常，应使用常量或确定有值的对象来调用equals

所有的相同类型的包装类对象之间值的比较，全部使用 equals 方法比较

 关于基本数据类型与包装数据类型的使用标准如下：1） 【强制】所有的 POJO 类属性必须使用包装数据类型。2） 【强制】RPC 方法的返回值和参数必须使用包装数据类型。3） 【推荐】所有的局部变量使用基本数据类型。

使用索引访问用 String 的 split 方法得到的数组时，需做最后一个分隔符后有无内容的检查，否则会有抛 IndexOutOfBoundsException 的风险。

集合处理

操作(增加/移除)

不要在 foreach 循环里进行元素的 remove/add 操作。remove 元素请使用 Iterator方式，如果并发操作，需要对 Iterator 对象加锁。

去重

利用 Set 元素唯一的特性，可以快速对一个集合进行去重操作，避免使用 List 的contains 方法进行遍历、对比、去重操作。

排序

在 JDK7 版本及以上，Comparator 实现类要满足如下三个条件，不然 Arrays.sort，Collections.sort 会报 IllegalArgumentException 异常。说明：三个条件如下 1） x，y 的比较结果和 y，x 的比较结果相反。2） x>y，y>z，则 x>z。 3） x=y，则 x，z 比较结果和 y，z 比较结果相同。

泛型集合

泛型通配符<? extends T>来接收返回的数据，此写法的泛型集合不能使用 add 方 法，而<? super T>不能使用 get 方法，作为接口调用赋值时易出错。说明：扩展说一下 PECS(Producer Extends Consumer Super)原则：第一、频繁往外读取内容的，适合用<? extends T>。第二、经常往里插入的，适合用<? super T>。

对比(hashcode和equals)

关于 hashCode 和 equals 的处理，遵循如下规则：1） 只要重写 equals，就必须重写 hashCode。 2） 因为 Set 存储的是不重复的对象，依据 hashCode 和 equals 进行判断，所以 Set 存储的对象必须重写这两个方法。3） 如果自定义对象作为 Map 的键，那么必须重写 hashCode 和 equals。

存储NULL

是否可以存储null

并发处理

公共资源类

资源驱动类

工具类

单例工厂类

线程池

线程资源必须通过线程池提供，不允许在应用中自行显式创建线程。

时间格式化

SimpleDateFormat 是线程不安全的类，一般不要定义为 static 变量，如果定义为static，必须加锁，或者使用 DateUtils 工具类。

如果是 JDK8 的应用，可以使用 Instant 代替 Date，LocalDateTime 代替 Calendar，DateTimeFormatter 代替 SimpleDateFormat，官方给出的解释：simple beautiful strongimmutable thread-safe。

定时任务

多线程并行处理定时任务时，Timer 运行多个 TimeTask 时，只要其中之一没有捕获抛出的异常，其它任务便会自动终止运行，使用 ScheduledExecutorService 则没有这个问题。

Random获取随机数

避免 Random 实例被多线程使用，虽然共享该实例是线程安全的，但会因竞争同一seed 导致的性能下降。

在 JDK7 之后，可以直接使用 API ThreadLocalRandom，而在 JDK7 之前，需要编码保证每个线程持有一个实例。

HashMap并发问题

HashMap 在容量不够进行 resize 时由于高并发可能出现死链，导致 CPU 飙升，在开发过程中可以使用其它数据结构或加锁来规避此风险。

控制语句

需要进行参数校验

1） 调用频次低的方法。2） 执行时间开销很大的方法。此情形中，参数校验时间几乎可以忽略不计，但如果因为参数错误导致中间执行回退，或者错误，那得不偿失。3） 需要极高稳定性和可用性的方法。4） 对外提供的开放接口，不管是 RPC/API/HTTP 接口。5） 敏感权限入口。

不需要进行参数校验

1） 极有可能被循环调用的方法。但在方法说明里必须注明外部参数检查要求。 2） 底层调用频度比较高的方法。毕竟是像纯净水过滤的最后一道，参数错误不太可能到底层才会暴露问题。一般 DAO 层与 Service 层都在同一个应用中，部署在同一台服务器中，所以 DAO 的参数校验，可以省略。3） 被声明成 private 只会被自己代码所调用的方法，如果能够确定调用方法的代码传入参数已经做过检查或者肯定不会有问题，此时可以不校验参数。

注释规约

其他

单元测试

在设计评审阶段，开发人员需要和测试人员一起确定单元测试范围，单元测试最好 覆盖所有测试用例。

Mysql数据库

建表规约

表的命名最好是加上“业务名称_表的作用”

单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。

索引规约

业务上具有唯一特性的字段，即使是多个字段的组合，也必须建成唯一索引。

超过三个表禁止 join。需要 join 的字段，数据类型必须绝对一致；多表关联查询时，保证被关联的字段需要有索引。

如果有 order by 的场景，请注意利用索引的有序性。order by 最后的字段是组合索引的一部分，并且放在索引组合顺序的最后，避免出现 file_sort 的情况，影响查询性能。

利用覆盖索引来进行查询操作，避免回表。

利用延迟关联或者子查询优化超多分页场景

SQL 性能优化的目标：至少要达到 range 级别，要求是 ref 级别，如果可以是 consts最好

1）consts 单表中最多只有一个匹配行（主键或者唯一索引），在优化阶段即可读取到数据。2）ref 指的是使用普通的索引（normal index）。 3）range 对索引进行范围检索。

建组合索引的时候，区分度最高的在最左边。

SQL语句

count(*)会统计值为 NULL 的行，而 count(列名)不会统计此列为 NULL 值的行

当某一列的值全是 NULL 时，count(col)的返回结果为 0，但 sum(col)的返回结果为NULL，因此使用 sum()时需注意 NPE 问题。

in 操作能避免则避免，若实在避免不了，需要仔细评估 in 后边的集合元素数量，控制在 1000 个之内。

ORM映射

在表查询中，一律不要使用 * 作为查询的字段列表，需要哪些字段必须明确写明。

】POJO 类的布尔属性不能加 is，而数据库字段必须加 is_，要求在 resultMap 中进行字段与属性之间的映射。

不允许直接拿 HashMap 与 Hashtable 作为查询结果集的输出。

@Transactional 事务不要滥用。事务会影响数据库的 QPS，另外使用事务的地方需要考虑各方面的回滚方案，包括缓存回滚、搜索引擎回滚、消息补偿、统计修正等

设计规范

系统架构设计的目的

1. 确定系统边界。确定系统在技术层面上的做与不做。2. 确定系统内模块之间的关系。确定模块之间的依赖关系及模块的宏观输入与输出。3. 确定指导后续设计与演化的原则。使后续的子系统或模块设计在规定的框架内继续演化。4. 确定非功能性需求。非功能性需求是指安全性、可用性、可扩展性等。