好用的代码

我见过最漂亮的好用代码，不是好用那些炫技的算法，也不是好用什么高深的设计模式。是好用几年前修过的一个bug，三行改动，好用让一个崩溃了半年的好用系统稳定运行到现在。

那是好用个老旧的支付模块，每天凌晨三点准时内存溢出。好用所有人都在查缓存策略，好用调JVM参数，好用甚至有人提议重写整个模块。好用没人愿意看那段代码——六千多行，好用没有注释，好用变量名是好用a、b、好用c这种。我花了两个通宵读完，最后发现问题出在一个HashMap上。某个业务场景下，key的hashCode会碰撞得特别厉害，导致链表过长。修复方式很简单：换用TreeMap，或者给那个类加个更好的hash方法。我选了后者，因为改动最小。

好用的代码不是给人欣赏的，是让人能睡个安稳觉的。

另一个例子是去年写的一个数据清洗脚本。需求很绕：从几十个不同格式的Excel里提取信息，再按规则合并。一开始我写了三百多行，用了一堆正则和条件判断。跑起来倒是没问题，但客户改了一次字段顺序，我就得改代码。后来我把所有映射关系抽出来，做成一个配置文件。代码缩到一百行以内，再遇到格式变化，改配置就行。客户自己都能维护了。

好的代码是能接受变化的代码，不是把变化写死的代码。

还有个反例。公司有个“代码洁癖”同事，特别追求设计模式。把简单功能硬套上工厂、观察者、策略，画了一堆UML图。代码是优雅了，但每次加需求都要动四五个类，测试要mock一堆接口。后来他离职了，没人敢动那块代码。三个月后，产品经理实在受不了需求排期，我们花了两周重写，功能一样，代码量砍了六成。

代码是写给人看的，不是写给模式看的。模式是工具，不是目的。

我自己的原则很简单：能跑、能改、能删。能跑是指不崩溃，能改是指加需求不用大动干戈，能删是指删掉某块功能不会牵连一堆隐藏依赖。这三条比什么“高内聚低耦合”实在多了。

打个比方，好代码像宜家家具——拆装说明书清楚，换个零件不用把整个柜子拆了。坏代码像祖传老房子，看着结实，想改个窗户得动承重墙。

前阵子接手一个开源项目，发现作者在关键函数里写了二十多行日志，每行都记录中间变量。当时觉得冗余，后来排查一个线上问题，正是靠那些日志定位到边界情况。我发邮件问他为什么写这么细，他说：“因为我知道三个月后看代码的人不是我自己，是那个被电话吵醒的倒霉蛋。”

那个倒霉蛋可能就是我，也可能就是你。

所以回到最开始的问题：什么代码好用？答案很简单——让你敢在周五下午五点改完代码去下班的代码，就是好代码。它不完美，但你知道它哪里可能有坑，而且这些坑都标了记号。真正的烂代码，是你看着它运行正常，心里却总觉得哪里不对，又说不出来哪里不对的那种。

写代码这事，本质上是在跟未来的自己对话。写清楚，是为了以后不被自己咒骂。写简单，是为了以后不用求别人帮忙。写可删，是为了以后能干净利落地重来。

就这些。挺朴素的。