避坑 | 早跟你说了不要写 hardcode！

想要成为编程大牛，不仅要具备充足的理论知识，还要有在实际项目中积累的编程经验和解决问题的能力。

有时，出于经验不足或者图省事儿，我们会在开发时写很多 hardcode。

什么是 hardcode？

hardcode，即硬编码，就是把未来可能发生变化的信息直接以固定变量的形式写在代码中，或者把一段特殊的逻辑写死。hardcode 会使得日后修改和维护代码变得困难。

下面列举几种常见的 hardcode：

1. 最常见的 hardcode 当属写死 ip 地址和数据库账号密码了，比如下面代码：

// 第三方接口的 IP 地址 private static final IP = 10.10.10.1; void doPost() { // 得到请求地址 String requestUrl = IP + '/getUser'; // 发送请求 ... } 

看似没什么问题，但是如果要请求的接口地址发生变化，而业务负责人没有收到通知或者未即时修改，会导致所有的请求失败！

2. 写死逻辑，比如在查询火车票价格时，针对特定 uid 的用户（比如某大客户）返回特殊的促销票价：

// 特殊用户直接返回票价 if (uid == 10001) { return 50; } else { // 从数据库查询票价 return db.getPriceByUid(uid); } 

以上好像还不能看出 hardcode 的危害有多大，如果项目代码都在自己的掌控之下，大不了数值变化时改代码呗。但是在大公司，或者人数众多的项目团队中，可能有些 hardcode 没那么容易被发现，hardcode 带来的影响和危害可以说是致命的！

下面我用自己悲伤的加班经历告诉大家，为什么不要写 hardcode。

一行 hardcode 助我加班

背景

公司内部有一个知名的消息队列服务，我负责的项目中用到了消息队列生产端进行消息的推送，供其他业务方订阅消息进行独立处理。

一般情况下，连接消息队列就和连接数据库一样，输入地址、账号、密码，直连消息队列生产者即可，如图：

但是有时我们不直接连接消息队列本身，而是连接代理，由代理负责将要发送的消息推送到不同的消息队列生产端，再进行发送，可以实现负载均衡。此时在代码中配置的地址是代理的地址而不是某一个具体的消息生产者，如图：

由于数据量很大，我们使用第二种模式，在代码中连接生产者代理，但之前代理使用的是固定的 IP 地址，代码如下：

final String IP = "10.10.10.2"; MessageProducer mp = new MessageProducer(IP, "xx", "xx"); 

风云突变

前几天，我正在恰可乐，该消息队列的服务团队突然发了个公告，内容如下：

这时，我才想起来那段 hardcode，改吧改吧。。。

下面是一顿操作：

1. 先在代码中把 IP 地址改为他们指定的域名

2. 用脚本检测我们线上机器到这个域名的网络连通性，千万别 ping 不通！

3. 确认连通性后，部署服务到测试环境，进行消息推送测试

4. 测试通过后，提交代码，等审批

5. 审批之后，灰度部署（只升级部分机器）

6. 观察无问题，全量部署

搞定？

深藏不露

如果这样就搞定了，那真是太谢天谢地了。

改 bug 不可怕，可怕的是，你不知道有没有 bug，bug 藏在什么地方。。。

原来所有使用这个消息队列的代码都配置的固定 IP，而此时我只是更换了自己负责的业务代码中的 IP 地址，但是我们依赖的其他服务（或者是一个 jar 包），有没有使用到这个代理，从而引入了 hardcode 呢？必须要全面且仔细地排查！

通过 gradle build –scan 命令扫描项目依赖的 jar 包，排查有没有这个消息队列的连接包。

经过排查，还真有一个 jar 包，使用该消息队列进行监控数据上报。在这个 jar 包中，静静地躺着似曾相识的 hardcode：

final String IP = "10.10.10.2"; MessageProducer mp = new MessageProducer(IP, "xx", "xx"); 

搞定 x 2？

慈航普渡

此时，只是解决了自己业务中的 hardcode，但是，使用这个包含过期 IP 的 jar 包的项目非常多，如果这些项目不对 jar 包进行升级的话，几天后用到这个 jar 包的项目都会受到影响！

既然看到了，不能不管吧！

于是，调查了所有可能使用这个 jar 包的团队，然后给他们发送了升级该 jar 的通知，这才终于搞定了！下班下班。

没想到，一行 hardcode 就带来了这么大的风险和工作量，善哉善哉。

既然 hardcode 危害那么大，有什么办法避免写 hardcode 呢？

如何避免 hardcode？

针对不同的 hardcode，有不同的处理方式，此处总结如下几个技巧。

1. 变量引用

最简单的做法，就是为相同的固定值定义一个变量（常量），最好在单独的类或文件中。这样，在修改时，只要修改一处即可。

错误代码：

String requestUrl1 = "10.1.1.1" + "/getUser"; String requestUrl2 = "10.1.1.1" + "/getSku"; String requestUrl3 = "10.1.1.1" + "/getOrder"; 

final String IP = "10.1.1.1"; String requestUrl1 = IP + "/getUser"; String requestUrl2 = IP + "/getSku"; String requestUrl3 = IP + "/getOrder"; 

2. 配置化

将所有可能改动的信息（比如数据库账号、密码、服务端口）单独存放到配置文件中进行管理，通过读取配置来获取信息。修改信息时只需要独立修改配置文件，而不用改动代码，非常方便，是目前项目开发中最常使用的一种方式。

示例配置文件：

server.ip = 10.1.1.0 server.port = 8080 db.username = yupi db.password = yupi 

String serverIp = Config.getConfig("server.ip"); 

3. 动态配置

通过配置化的方式已经能够解决项目中的 hardcode，但还有一个问题，就是改动配置后，项目可能需要重新启动才能让新配置生效，还不够灵活。

为此，我们可以利用分布式配置中心实现动态配置，将所有的配置存放在数据库或分布式缓存、Etcd 中，通过在业务代码中引入 SDK 来监听配置变量。当配置发生修改时，变量的值会同步进行修改，而无需重启项目。

现在比较主流的配置中心有携程的 Apollo、阿里 Nacos 和 Spring Cloud Config 等，很多配置中心提供了可视化的界面，可以方便地进行配置管理、修改发布和版本控制。

携程 Apollo 控制台

如果觉得有帮助，记得分享给小伙伴，再写硬代码头打烂！

有道无术，术可成；有术无道，止于术

欢迎大家关注Java之道公众号

好文章，我在看❤️