1、参数校验
说明：每次开始编写一个service，首先要做的就是参数校验。各种不为NULL、不为空的代码随处可见，很不爽。所以我们要找一种方法，来简化这部分的业务无关代码。
1.1. Apache给我们提供了一个工具类可以满足我们的需求：org.apache.commons.lang3.Validate，提供了各种校验notBlank、notEmpty、notNull等，可以满足我们的一般需求。还可以自定义未通过校验的提示语。
try {
long num = 40;
Validate.exclusiveBetween(1, 10, num, "num参数不在1-10范围内");
}catch (Exception e){
e.printStackTrace();
}
1.2. Guava的Preconditions也实现了类似的功能。
Preconditions.checkArgument(!(StringUtils.isEmpty(userName)
|| StringUtils.isEmpty(password)), "用户名或密码不能为空");
1.3. 实体类约束检查：Hibernate-validator
BeanValidators.validateWithException(validator, dto);
2、分支判断
说明：选择正确的判断语句会对性能有所提升。所以我们要合理的运用switch case、if else、while、for。
-
如果分支的条件判断都是等值判断，且值的范围较小，则应该使用switch case而不是if else。因为switch内部维护了一个路由表，不需要像if else那样挨个判断。但是如果判断是范围，则只能用if else来操作了。
-
双层for循环判断的情况：把内层for拿出来，转换成字典。
-
使用策略模式和多态去掉if/else、switch
参考1
参考2 利用设计模式替代项目中的if else
注： if else 并不都适合用策略模式替代，只有每个分支足够复杂，且每个分支用不同方法做同一件事，才需要使用策略模式。
3、编译阶段做检查
改变编码方式，在编译阶段做错误检查，而不是等到运行阶段。
比如switch，如果参数拼写错误，会走default分支，导致不可预测的结果。但是如果参数改为enum类型，则编译阶段就会发现该错误，及时改正。
4、方法可见性
对共有方法进行判定，是否需要公布。
5、不断去发现更新工具类
不应该一直使用项目里一些老旧的工具类，应该不断的去发现探索新的好用的工具类，例如Apache Commons、Google Guava或者Joda Date。
6、静态导入使用
Eg: import static com.google.common.base.Preconditions.checkNotNull;
好处：减少代码的书写量；可读性高。
缺点：如果滥用，可读性会很差，代码中都是方法名，看不到类名，类是极具描述性的表示的。
所以，如果方法具有很好的表述性含义，则建议多用静态导入。对于枚举类，还是建议老老实实的书写。
7、避免脏数据
宁愿让程序出错、停止运行，也不要把一些错误的数据插入到数据库。正式的线上系统，数据的准确性是最重要的。操作前，一定要反复的进行数据检查。
第一步：基本判断约束(null值等基本判断)
第二步：实体属性约束(满足jsr 303等基础判断)
第三步：业务条件约束(需求提出的不同的业务约束)
第四步：处理业务逻辑
Eg: 下面贴出一段用户发表文章的示例代码：
public ResponseEntity addArticle(Integer uid, Article article) {
//参数数据检验
// 1.用户id不能为空，且此用户存在
Preconditions.checkNotNull(uid);
User user = userDao.findOne(uid);if(null== user){
throw new RuntimeException("找不到当前用户!");
}
// 2.文章的必要字段不能为空
BeanValidators.validateWithException(validator, article);
// 业务逻辑代码
article.setUser(user);
ResponseEntity ret = articleDao.save(article);
return ret;
}
后面会抽时间不定期补充
网友评论