我放弃整洁代码的那一刻

我被安排到一个项目里，那简直一团糟。他们告诉我，负责建造的人是个专业人士，但由于时间非常紧迫，所以成品有点粗糙。

我不相信。

我当时想：“写这玩意儿的人真是个白痴。”函数到处乱放，代码毫无逻辑可言，命名也糟糕透顶。没错，命名确实很难，但这函数名跟代码实际功能完全不符……

我当时想——简洁的代码很重要。我喜欢简洁代码的样子：函数小而精炼，函数名简短，函数上方还有注释，注释周围用短横线框起来，更加醒目。真漂亮。

另一个故事：

前段时间，我曾与一位技术娴熟的程序员合作过另一个项目。

他一再推迟发布。“我得先重构一下，” “在处理下一个任务之前，我需要花一周时间清理代码，” “天哪，我今天花了一整天时间拆分一个5000行的文件……”

他对此非常认真。而且他做得也不错，但人都会犯错，他重构的5000行代码又导致了新的bug，这些bug需要修复，然后又需要进行另一次重构。

每次我在博客文章中提到整洁代码时，都会收到一些评论，询问它为什么如此重要，以及每个人都应该如何遵守编码规范的“圣经”。

“慢慢来，把代码清理干净。”他们说，“让代码比你发现它的时候更好。”

这让我想起了关于“收件箱清空”的争论。想象一下，一个空空如也的邮箱。多么美好！虽然需要花些功夫清理，但看看这美好的空虚吧。

毕竟，这不就跟保持家里清洁一样吗？谁也不想家里垃圾堆积如山。保持家里清洁——保持办公桌清洁——保持收件箱清洁——编写简洁的代码？

度假回来后，我的邮箱又被塞满了。你必须每天都密切关注邮箱，而且最好迅速处理，否则它很快就会再次爆满。这虽然只是些简单的收尾工作，但每天都做这些事，积少成多，最终就变成了一项繁重的任务。这很烦人，而且保持邮箱整洁也让我压力很大。

蒂姆·费里斯的《每周工作4小时》让我重拾信心。这本书的核心观点之一是：我们80%的时间都浪费在无意义的事情上（帕累托法则）。清空收件箱是拖延症。在代码注释周围加破折号也是拖延症。你处理垃圾邮件的每一秒都是浪费。这很简单，人人都能做到。书中有一句名言，大意是：“我是否在编造各种事情来逃避真正重要的事情？”

后来我实在忙不过来，根本没精力处理那些乱七八糟的事情。于是我放弃了，任由收件箱爆满。虽然心里痒痒的，但同时我也感到如释重负。我放手了。就这么放手了。邮件源源不断地涌来，但我再也不在乎了。

你猜怎么着——你会习惯的。

而且你的搜索能力也会越来越强。

以及过滤。

快速浏览新闻标题。

还有阅读晦涩难懂的代码。

以及如何驾驭混乱的代码库。

偶尔你会错过一些东西。

你必须接受这一点。

然后你会收到提醒，然后你就得处理它。

代码的第一个版本本来就应该比较混乱。使用几周或几个月后，你会发现其中的缺陷。当需要扩展功能时，再去修复。只修复重要的部分。如果之后不再修改，那就让它保持混乱状态吧。

我不是说“对同事耍花招”。别为了乱而乱，搞得一团糟。别再画画了，把精力放在重要的事情上吧。

凌乱的房子和混乱的代码库之间的区别在于，在编程中，我们有工具来驾驭它。

不要试图一次性重构一个 5000 行的文件。这会耗费大量时间，而且你会犯错。这是一种拖延症。

修复使用函数时出现的命名错误。如果修复了函数中的错误，请重写该函数。

找出并解决导致头痛的根本原因。

微小改进——较小的提交。

让代码比你最初发现它时更好。