你必须解决它随着时间的推移，很多程序里都会慢慢积累一些看似没用的或废弃的代码，没人敢动它们，因为担心会
你必须解决它
随着时间的推移，很多程序里都会慢慢积累一些看似没用的或废弃的代码，没人敢动它们，因为担心会把程序弄坏。我认为，这些代码借助于人们对它的缺乏了解，害怕修改程序——这其实是源于一种迷信，而非出于理智——而驻留在程序里，成为了一种具有最隐蔽形式的技术债务。你也许在处理这些代码时会把程序弄坏，但你必须处理掉它们——为了坚守你的理智，为了保持程序的健康。
?
几周前，一个主要由我负责的我们的基础系统里的一个服务开始表现出反常现象。其中有一个线程的CPU使用率时不时会冲上100%，偶尔会减退平息，但大多数会保持高位，留下一排让人烦恼的Munin监控图，它的每次冲锋都像是对我的嘲弄。通过一些查找发现了两个问题，我研究了好几天，结果却发现那只是障眼法，根本不是问题的根源。
正好赶上假期，我把绝大部分的时间都花在了我们生产环境集群服务器的一个节点上，试图能明白这个问题的成因(这个现象只在生产环境且有一定的并发时才会出现，在测试环境中无法复制，即使加到10倍的负载)。从凌晨2点到4点，不知损失了多少脑细胞，我胡乱的在程序里加入bug调试，异常捕捉(尽管没有任何迹象显示有异常抛出)的代码，以及其它一些胡乱的，让人后怕的没用代码。最终，我发现了在一个资源竞争的条件判断中一个套接字标志可以被设置成SO_WRITE，却从来没有被清除。这会导致在While(true)循环里的Selector.select()调用立即退出，而不是耐心的等待一个网络IO事件发生，这最终导致了一个自我循环的线程占用100%CPU负荷的现象。幸运的是，这个问题并没有影响到这个服务的运行。修改了一下程序解决了这个问题后(只是把一行代码剪切到原位置的下两行)，服务运行的非常的好，这个劳动节剩下的一个周末我在旧金山过的很愉快。
你必须解决它。
假期结束回到办公室后，我向我那充满耐心、热心帮助的同事为此事说了一大篇解释和抱歉的话，然而之后，我突然感觉到有些后怕，我在程序里留下了那么多没用的显示log信息的、捕捉无意义异常的、其它的乱七八糟的代码，我害怕去碰它们了。理由站不住脚，这是害怕去改动能够正常运行的程序，尽管这些都是迷信。
编程是一种科学，我们所有的系统都是基于其中的一些原则、约定和API(数学，POSIX，编程语言)。因为我知道这些各个层面上的知识，这些保证了我不会产生没有根据的怀疑和恐惧，我不会让自己在这些问题面前吓的不敢乱动。迷信在编程中是没有用的——你可以问问任何一个能花上一两天去跟踪内存泄漏问题的程序员。
我们面对的任务并不是“找出为什么运行异常”，而是去发现编程语言的哪种写法触发了这种不期望的行为。抛弃恐惧、误解、抱怨的思想习惯，要想到计算机程序有它自己的规则，我们擅长于理顺它们。当然，最终，我的程序经过整理，完全按照我要求的方式精确的运行。它的工作流程我重新掌握的一清二楚，我又重新控制了它。
如果你的程序让你害怕，你应该解决它，直到你不再怕它为止。
?
?
翻译来源：外刊IT评论
?
?
;-)
23 楼 21505720 2010-10-29 不允许跑火车 24 楼 wt13621775942 2010-10-29 楼主的文章，和后面人的回复都很经典的嘛。累积更多，沉淀更多，得到更多。 25 楼 zhang_xzhi_xjtu 2010-10-31 主贴不错，不过一个程序员加一堆无用的的东西显得很不专业啊。有点挑刺了。 26 楼 houxinyou 2010-11-01 aninfeel 写道弄好了领导不会奖励你，但是弄坏了的话……hoho
现在所在的领导都是这样的，所以有时发现代码中有坏味道时是不会有人重构的，因为如果出现错误，这个风险是没人替你担的
27 楼 ownraul 2010-11-02 houxinyou 写道aninfeel 写道弄好了领导不会奖励你，但是弄坏了的话……hoho
现在所在的领导都是这样的，所以有时发现代码中有坏味道时是不会有人重构的，因为如果出现错误，这个风险是没人替你担的
可以没有功,但一定不能有过
反正这也是现实问题了,很可能写好了的东西以后才会发挥它的作用,这种自找苦吃让后来人获益的事情,现在很少有人做了..很浮躁的社会了... 28 楼 abraham_xi 2010-11-02 问题解决了就好 29 楼 abraham_xi 2010-11-02 houxinyou 写道aninfeel 写道弄好了领导不会奖励你，但是弄坏了的话……hoho
现在所在的领导都是这样的，所以有时发现代码中有坏味道时是不会有人重构的，因为如果出现错误，这个风险是没人替你担的
说的太对了，有好多代码感觉不好需要重构，但是系统在运行呀，怎么办？？？？改还是不改？？？？ 30 楼 jnoee 2010-11-02 abraham_xi 写道houxinyou 写道aninfeel 写道弄好了领导不会奖励你，但是弄坏了的话……hoho
现在所在的领导都是这样的，所以有时发现代码中有坏味道时是不会有人重构的，因为如果出现错误，这个风险是没人替你担的
说的太对了，有好多代码感觉不好需要重构，但是系统在运行呀，怎么办？？？？改还是不改？？？？
我觉得不好的地方一定要改，不给时间加班也要改掉。 31 楼 houxinyou 2010-11-02 jnoee 写道abraham_xi 写道houxinyou 写道aninfeel 写道弄好了领导不会奖励你，但是弄坏了的话……hoho
现在所在的领导都是这样的，所以有时发现代码中有坏味道时是不会有人重构的，因为如果出现错误，这个风险是没人替你担的
说的太对了，有好多代码感觉不好需要重构，但是系统在运行呀，怎么办？？？？改还是不改？？？？
我觉得不好的地方一定要改，不给时间加班也要改掉。
改完没有问题当然好了，大家都希望是，但是问题谁也不敢保证不出，当你重构出了问题后，第一次领导说你几句，第二次就要骂人了，第三次，恭喜你，能换一份新的工作了 32 楼 tuti 2010-11-03 houxinyou 写道
改完没有问题当然好了，大家都希望是，但是问题谁也不敢保证不出，当你重构出了问题后，第一次领导说你几句，第二次就要骂人了，第三次，恭喜你，能换一份新的工作了
所以说，80%以上的问题，都是系统性的问题，也就是管理的问题，而不是个人的问题。
如果重构后出现问题，就拿具体的程序员当作源头来问责，就是把系统性问题当作个别问题来处理，于事无补。
33 楼 miaow 2010-11-08 tuti 写道houxinyou 写道
改完没有问题当然好了，大家都希望是，但是问题谁也不敢保证不出，当你重构出了问题后，第一次领导说你几句，第二次就要骂人了，第三次，恭喜你，能换一份新的工作了
所以说，80%以上的问题，都是系统性的问题，也就是管理的问题，而不是个人的问题。
如果重构后出现问题，就拿具体的程序员当作源头来问责，就是把系统性问题当作个别问题来处理，于事无补。
呃，其实领导没错，花钱请人做事是让系统能跑、这样才能创造价值，花钱是为了赚钱的。
如果坏味道不对系统性能有大影响、不严重影响未来演进，冒改错了的风险根本不值得。
不知道是不是我做的系统很大比例和钱打交道的业务系统闹的我和很多同仁的第一反应不一样，呵呵，做频繁升级的桌面软件的或者永远在路上的web2.0应用的应该和我这样的屁股不在一边。
34 楼 咖啡豆子 2010-11-15 原帖作者是幸运的，至少出问题的是自己写的东西 35 楼 ygzx 2010-12-11 没有版本控制吗?
比较一下就知道改了那里，去掉垃圾留下精华就行了
其实我也很怕，所以我写程序至少两遍
第一遍can do
第二遍do well 36 楼 noahweb 2010-12-29 ygzx 写道没有版本控制吗?
比较一下就知道改了那里，去掉垃圾留下精华就行了
其实我也很怕，所以我写程序至少两遍
第一遍can do
第二遍do well
不要害怕自己的代码..... 37 楼 peterwei 2010-12-29 houxinyou 写道jnoee 写道abraham_xi 写道houxinyou 写道aninfeel 写道弄好了领导不会奖励你，但是弄坏了的话……hoho
现在所在的领导都是这样的，所以有时发现代码中有坏味道时是不会有人重构的，因为如果出现错误，这个风险是没人替你担的
说的太对了，有好多代码感觉不好需要重构，但是系统在运行呀，怎么办？？？？改还是不改？？？？
我觉得不好的地方一定要改，不给时间加班也要改掉。
改完没有问题当然好了，大家都希望是，但是问题谁也不敢保证不出，当你重构出了问题后，第一次领导说你几句，第二次就要骂人了，第三次，恭喜你，能换一份新的工作了
其实要看什么情况下。在开发和测试阶段，有小问题，小重构的，肯定要改的嘛。大的问题，会影响到进度的，要向上提出来，进行评审的，哪能想改就改。至于生产环境下，就更要向上提出进行评审修改的风险了。大些的项目也有版本控制吧，不是说改完就能放过去吧，有些国企单位的项目做版本变更的话，要层层审批的。 38 楼 Mybeautiful 2011-03-02 如果我维护的代码有改进的空间，我是一定要改的(不管他是谁写的)，哪怕代价很大，也有一定的风险，并且我也这样要求手下人。因为这段垃圾代码总是归我维护，今天不改好，以前也是我的事情。每改一个模块，自己对结构都了然于心，以后工作就越来越顺手。
当然改的太好了，说不定我也该失业了。 39 楼 feng02120 2011-03-28 你必须解决它，说起来其实对一个系统维护人员挺残酷的
