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

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

图中的反例是将数据缓存起来，并使用魔法值加链路 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架构师联盟，每日更新技术好文

一本阿里开发手册，很简单，却让我如此沉迷相关推荐

【阿里开发手册】所有的类都必须添加创建者和创建日期——在Idea中创建类时自动添加作者信息
一.前言阿里开发手册强制的建议--所有的类都必须添加创建者和创建日期,我觉得很合适,自己写的过了几个月忘记,一看名字就知道是自己写的.出现问题,一看谁写,直接叫他解决bug很香啊!今天记录一下怎么设 ...
《Java Web开发入门很简单》学习笔记
<Java Web开发入门很简单>学习笔记 1123 第1章了解Java Web开发领域 Java Web主要涉及技术包括:HTML.JavaScript.CSS.JSP.Servlet ...
五岳核心版上线，这份阿里开发手册核心版又将被多少人疯狂转载？
学习是一种基础性的能力.然而,"吾生也有涯,而知也无涯.",如果学习不注意方法,则会"以有涯随无涯,殆矣". 学习就像吃饭睡觉一样,是人的一种本能,人人都有学习 ...
记-阿里开发手册规范(JAVA)
从接触java以来,我们一直学习着各种技术和架构.但我们常忽略代码可读性和一些特殊的规范和约定.有很多人尤其是新人写的代码,运行可能没什么问题.但却不忍直视,甚至内涵风险.业内代码规范可能各有各的理解 ...
阿里开发手册mysql_MySQL 开发准则（总结自阿里巴巴开发手册）
命名规范 [强制]对象名称必须用小写或者小写.下划线.数字组成. name;user_name; [强制]对象名称禁止使用 MySQL 保留关键字. 如 ORDER 等 [强制]对象名称要见名知其意, ...
Java 集合（List、Set）与数组(Arr)互转方法及注意事项，难怪《阿里开发手册》会如此重视
原创博文,欢迎转载,转载时请务必附上博文链接,感谢您的尊重. 前言: 如果你现在正急于解决问题,请立刻.马上拉到本篇最后的[总结],进入"不废话环节". 通过本篇的学习,你将全面掌 ...
阿里开发手册精髓知识点总结
Mysql篇================ 小数类型为decimal,禁止使用float和double. 说明:在存储的时候,float和double都存在精度损失的问题,很可能在比较值的时候,得到 ...
IOS多线程开发其实很简单
http://blog.csdn.net/shenjie12345678/article/details/44152605 转载于:https://blog.51cto.com/8399249/165 ...
阿里开发手册学习记忆理解表达融会贯通
BigDecimal 用compareTo 会比较精度(不要用 equals 了) , 如果结果是0, 就是相等 hashmap 叫resize 而不是扩容,没有二义性的话

一本阿里开发手册，很简单，却让我如此沉迷

静态常量取代魔法值#

枚举类取代魔法值#

总结

一本阿里开发手册，很简单，却让我如此沉迷相关推荐

最新文章

热门文章