你必须解决它zZ

作者 cscotta

随着时间的推移，很多程序里都会慢慢积累一些看似没用的或废弃的代码，没人敢动它们，因为担心会把程序能坏。我认为，这些代码借助于人们对它的缺乏了解，害怕修改程序——这其实是源于一种迷信，而非出于理智——而驻留在程序里，成为了一种具有最隐蔽形式的技术债务。你也许在处理这些代码时会把程序能坏，但你必须处理掉它们——为了坚守你的理智，为了保持程序的健康。


几周前，一个主要由我负责的我们的基础系统里的一个服务开始表现出反常现象。其中有一个线程的CPU使用率时不时会冲上100%，偶尔会减退平息，但大多数会保持高位，留下一排让人烦恼的Munin监控图，它的每次冲锋都像是对我的嘲弄。通过一些查找发现了两个问题，我研究了好几天，结果却发现那只是障眼法，根本不是问题的根源。

正好赶上假期，我把绝大部分的时间都花在了我们生产环境集群服务器的一个节点上，试图能明白这个问题的成因(这个现象只在生产环境且有一定的并发时才会出现，在测试环境中无法复制，即使加到10倍的负载)。从凌晨2点到4点，不知损失了多少脑细胞，我胡乱的在程序里加入bug调试，异常捕捉(尽管没有任何迹象显示有异常抛出)的代码，以及其它一些胡乱的，让人后怕的没用代码。最终，我发现了在一个资源竞争的条件判断中一个套接字标志可以被设置成SO_WRITE，却从来没有被清除。这会导致在While(true)循环里的Selector.select()调用立即退出，而不是耐心的等待一个网络IO事件发生，这最终导致了一个自我循环的线程占用100%CPU负荷的现象。幸运的是，这个问题并没有影响到这个服务的运行。修改了一下程序解决了这个问题后(只是把一行代码剪切到原位置的下两行)，服务运行的非常的好，这个劳动节剩下的一个周末我在旧金山过的很愉快。

你必须解决它。

假期结束回到办公室后，我向我那充满耐心、热心帮助的同事为此事说了一大篇解释和抱歉的话，然而之后，我突然感觉到有些后怕，我在程序里留下了那么多没用的显示log信息的、捕捉无意义异常的、其它的乱七八糟的代码，我害怕去碰它们了。理由站不住脚，这是害怕去改动能够正常运行的程序，尽管这些都是迷信。

编程是一种科学，我们所有的系统都是基于其中的一些原则、约定和API(数学，POSIX，编程语言)。因为我知道这些各个层面上的知识，这些保证了我不会产生没有根据的怀疑和恐惧，我不会让自己在这些问题面前吓的不敢乱动。迷信在编程中是没有用的——你可以问问任何一个能花上一两天去跟踪内存泄漏问题的程序员。

我们面对的任务并不是“找出为什么运行异常”，而是去发现编程语言的哪种写法触发了这种不期望的行为。抛弃恐惧、误解、抱怨的思想习惯，要想到计算机程序有它自己的规则，我们擅长于理顺它们。当然，最终，我的程序经过整理，完全按照我要求的方式精确的运行。它的工作流程我重新掌握的一清二楚，我又重新控制了它。

如果你的程序让你害怕，你应该解决它，直到你不再怕它为止。