好的代码，是不需要反复维护的代码

衡量一段代码写得好不好，其中一个标准是：它写完以后，还需要你回来改多少次。

当然，只要业务需求不断变化，代码就不可能永远不动。我这里说的，是通过设计和编程手法，让代码尽可能稳定，让变化尽可能发生在代码之外。

我之前写过一篇《适合中小型企业的出口入口网关微服务》，里面有一个很明显的特点：这个网关上线以后，半年甚至一年都不需要发布一次。

这其实就是我理解的好代码。

第一，异常来了，不需要临时补代码

很多系统刚上线的时候看起来没问题，但流量一上来、第三方一挂、参数一异常，就开始不断打补丁。

今天补一个超时，明天加一个重试，后天再处理一个线程池问题。

最后代码越来越复杂，程序员也越来越忙。

更好的做法，是在设计的时候就把这些问题考虑进去。

流量突然增加，有限流。

第三方服务不稳定，有超时、重试和降级。

异常请求进来，有参数校验。

这些事情不是出了问题以后再去补，而是在系统设计之初就考虑进去。

这样做的结果是：系统面对常见的异常情况，可以自己扛过去，而不是每次都等程序员来救火。

对程序员来说，这种感觉其实很好。

一个功能写完以后，半年下来都没有因为Bug找你，没有因为异常场景让你回来改代码，它就在那里稳定地运行。

这不仅是质量，也是效率。

因为你的时间没有反复花在修补过去的代码上，而是可以继续做新的事情。

第二，需求变了，不一定需要改代码

还有一种更高级的稳定，是代码不变，也能适应业务变化。

还是拿我之前做的网关来说。

如果已经把某个第三方系统的接入方式封装好了，那么以后业务再提出需求，要接这个第三方系统的新接口，很多时候根本不需要修改网关。

因为变化发生在接口层面，而不是接入方式本身。

这和另外一种做法差别很大：

每接一个新接口，就改一次网关；

再来一个需求，再改一次；

过半年，这段代码已经改了十几次。

这种代码看起来一直在适应需求，实际上是在不断积累维护成本。

真正好的抽象，是同一类变化来了以后，不需要重复修改底层代码。

所以，好代码不一定是代码量少，也不一定用了多少设计模式。

我更看重的是两个结果：

异常来了，它能自己扛住；

需求变了，它不需要反复修改。

做到这两点，代码才能真正稳定下来。

程序员其中一种成就感，就是有时候回头看，发现半年一年前写的那段代码，居然一直没动。

写一次，稳定运行很久；变化来了，也不需要频繁维护。

这可能才是工程师真正应该追求的代码质量。