最近，无意中从网上搜索到一本很神奇的书籍，书籍来源是一个神奇的公司–阿里，看名字我以为内容很简单，就是单纯的一本开发手册，然后我就没有继续看，可是在某一个深夜，吃鸡成盒了几次之后，“气急败坏”的转战小说，在电子书中又看到这本书，本着深夜苦读的精神状态，于是，我就打开“仔细”的品读起来。

可是，真的是处于程序员的基因吗？我居然被吸引了，比方说这一条开发规范，是关于关于常量定义的规约，具体内容如下：

图中的反例是将数据缓存起来，并使用魔法值加链路 id 组成 key，这就可能会出现其他开发人员在复制粘贴的时候，少复制 _ 的情况发生，这种错误很难去检查到，因为读取缓存不存在，可能会去数据库读取，很难察觉到。

如果在生产环境中，大量的请求进来，缓存全部失效，直接请求数据库，导致数据库连接过多，查询效率变低的问题发生，因此看来魔法值确实应该避免出现在代码中。

另外其他的类似规范的书中也提到了类似的问题，在代码中出现原始形态数字通常来说是坏现象，应该用命名良好的常量类隐藏它。

静态常量取代魔法值#

像下面这个例子：

 Copyif (billCount > 75) {     //todo } else {     //todo } 

如果在不了解这块的业务的同事，在读到这块代码的时候，可能会想，75 是什么鬼，为啥和这个数比较，背后深藏着什么秘密吗？可能只有当时的开发人员记得了，导致代码可读性和可维护性极差。

如果声明一个常量，来替换该魔法值，可能就会使代码的可读性和可维护性大大增加。

 Copystatic final Integer BASIC_BILL_COUNT = 75; 

还有些魔法表达式，比如：

 Copyif (value > 60 && value <= 80 && type = 1) {     // todo } 

比如这个表达式是表示状态为正常且项目活跃，就可以定义：

 Copyboolean isActiveProject = value > 60 && value <= 80 && type = 1; 

这样是不是可读性就提高了，一眼就可以看出来这块代码的逻辑。

枚举类取代魔法值#

还有一种消除魔法值的方式是使用枚举类代替，下面让我们举个例子：

 Copyif (eventId == 1) {     System.out.println("睡觉"); } else if (eventId == 2) {     System.out.println("吃饭"); } else if (eventId == 3) {     System.out.println("打豆豆"); } 

如上代码是针对事件 id 去执行相应的事件，如果事件比较少，大家还可以勉强记住每个 eventId 对应的含义，但是随着事件 id 的增多，很可能会发生，新来的员工把事件 id 给搞混了，导致执行错误的事件，发生 bug。

那么我们可以使用枚举类来表示相应的事件：

 Copypublic enum EventEnum {      /**      * 睡觉      */     SLEEP_EVENT(1, "睡觉"),      /**      * 吃饭      */     EAT_EVENT(2, "吃饭"),      /**      * 打豆豆      */     FIGHT_PEA_EVENT(3, "打豆豆");      private int eventId;     private String desc;      EventEnum(int eventId, String desc) {         this.eventId = eventId;         this.desc = desc;     }      public int getEventId() {         return eventId;     }      public String getDesc() {         return desc;     } } 

修改完之后的代码如下：

 Copyif (eventId == EventEnum.SLEEP_EVENT.getEventId()) {     System.out.println("睡觉"); } else if (eventId == EventEnum.EAT_EVENT.getEventId()) {     System.out.println("吃饭"); } else if (eventId == EventEnum.FIGHT_PEA_EVENT.getEventId()) {     System.out.println("打豆豆"); } 

是不是可读性急剧提升，还不快看看自己代码中有没有这样的魔法值出现，有的话赶紧改造起来。

还有如果你需要在不同的地点引用同一数值，魔法数会让你烦恼不已，因为一旦这些数字发生改变，就必须在程序中找到所有的魔法值，并将它们全部修改一遍，这样就太费时费力了。

其实不只是 Java 不应该在代码中使用魔法值，其他语言亦是如此。

总结

本文主要介绍了为什么不允许在代码中出现魔法值以及如何将代码中已有的魔法值去除掉。

代码可读性还是比较重要的，你肯定不希望别人在接手你的代码的时候，骂到这数字啥意思，这代码写得跟粑粑一样。

最后，不知道你是否看过这本开发手册，其实这本书最初的目的是为了解决一些在代码编程中的理念之争，而这些理念之争的本质就是自己多年代码习惯生的茧，不愿意对不一样的风格妥协，不愿意为了团队的整体效能提升而委屈自己。其实，很多编程方式客观上没有对错之分，一 致性很重要，可读性很重要，团队沟通效率很重要。有一个理论叫帕金森琐碎定律:一个组织中的成员往往会把过多的精力花费在-些琐碎的争论上。程序员天生需要团队协作，而协作的正能量要放在问题的有效沟通上。个性化应尽量表现在系统架构和算法效率的提升上，而不是在合作规范上进行纠缠不休的讨论、争论，最后没有结论。规范不一，就像下图中的小鸭子和小鸡对话-一样， 言语不通，一脸囧相。鸡同鸭讲也恰恰形容了人与人之间沟通的痛点，自说自话，无法达成一一致意见。再举个生活中的例子，交通规则靠左行还是靠右行，两者孰好孰坏并不重要，重要的是必须要在统一的方向上通行，表面上限制了自由，但实际上是保障了公众的人身安全。试想，如果没有规定靠右行驶，那样的路况肯定拥堵不堪，险象环生。同样，过分自由随意、天马行空的代码会严重地伤害系统的健康，影响到可扩展性及可维护性。

而我如此喜欢这本书的原因，主要是因为现在市面上，对于编程人员的素质要求更高了，试想一下，如果你的代码质量较高，在同样的业务能力下，老大更喜欢谁呢？

关注公众号：Java架构师联盟，每日更新技术好文