在最近的小云通知项目中，我负责维护后端的开发，也是深刻体会到用魔法值会给维护人员带来多大的痛苦！可谓一个bug改一天……
文章目录
什么是魔法值
首先我们说一下什么是魔法值，所谓魔法值，就是未经预定义的常量，在阿里巴巴java开发手册上也明确规定，不允许使用魔法值。
这里我们发现，由于B同学用 Id#taobao 来提取缓存中的内容，但是少了下划线，因为缓存中没有匹配的 key 与之相对应，所以在缓存中根本找不到，数据只能去数据库中查找。如果数据量少，那影响比较小，但是如果是几百万条数据，那对于数据库的开销真的是比较严重，查询效率也会随之变慢。
所以在代码中禁止出现魔法值也是必须的。
怎么处理魔法值
知道了魔法值的危害，那么我们就将去解决这个问题
例子一：
if (peopleSum >= 35) {
//todo
} else {
//todo
}
这如果让维护人员看，就会感到莫名奇妙，为什么偏偏这么多变量中会有一个35，这个35是什么意思。不知道有没有人像我一样，忽然在一堆业务逻辑里出现一个未定义的常量，头大啊！
那么我们怎么去处理呢？
我们可以声明一个定义的常量来代替35
static final Integer INITIAL_NUMBER = 75;
用常量来说明这是一个初始人数
例子二：
if (notify.getCateId() == 1) {
//todo
} else if (notify.getCateId() == 2) {
//todo
}
这里是判断通知的类型，1、2 为数据库中通知类型的id，但是我们会发现，如果让没有接触过的人来看，就会很奇怪，1 代表的是什么，2代表的是什么，加大了维护的难度。
我们可以构造一个枚举类去代替。
@Getter
@AllArgsConstructor
@NoArgsConstructor
public enum NotifyCaseEnum {
MEETING(1, "会议通知"),
SOLITAIRE(2, "接龙"),
TASK(3, "作业");
private int code;
private String msg;
}
这样不管是开发人员还是维护人员，在读代码的时候也是清楚明了，方便性大大提升。
所以我们在开发的时候，及时项目规范中没有写出，我们也应该有自我意识，认识到代码的规范性，写出高效优雅得到代码质量。
大家有任何建议和想法也可以在下方评论，一起进步，加油