遗留程序有两种

在《程序员的定义》中，令狐在回复里，以及他后来的一篇《[随笔]测试、Debug、软件改进（与猎手的谈话录）》都谈到了一个很重要的问题，那就是：遗留代码的问题。

令狐认为，应该对遗留代码“给予足够的尊重”。在一定程度上的确是这样的，特别是在刚接触这些代码的时候，无论你觉得它们多么滥，但它们毕竟是久经考验，逐渐形成的，冒失地对其作大的改动，很可能是走回头路。

当然尊重也不是绝对的，该改的还是要改。我觉得遗留代码至少有两种：

一 种是开始设计得很好，但随着需求变化或对需求理解的深入，逐步改进。或是开始不太好，但随着一步步的优化改进，慢慢变好。这样的代码虽然乍一看有一些不合 理的地方，但是经过仔细分析，其实是不得已而为之——比如减小改动造成的影响，或是性能考虑（有时出于性能考虑，不得不牺牲很多的清晰性）。

另一种是开始就不好，而且为了适应需求变化或对需求的理解，用了各种权宜之计来实现。或是开始还好，但在随着需求变化而改动的过程中没有及时消除坏味道而变得越来越坏的代码。

当然，这两种遗留代码至少有一个共同点是：可以实现现有需求。如果连现有需求都不能实现的垃圾代码就不用讨论了。

对于前一种代码是没什么说的，一定要尊重，最多是在它没有单元测试的情况下给它补上这一课就好。而对于后一种代码，则有改进的必要。

不过改动毕竟是风险比较大的，所以我强调TDD。但“没有银弹”的教诲还是要时刻铭记于心的，不止是TDD，包括敏捷方法及重方法论，都不是银弹。人，始终是软件开发中最重要的因素。令狐在《测试先行的敏捷方法》中的回复说得没错，对于新手来说，TDD甚至未必比直接Coding有利。

但我仍然要鼓励TDD，因为修改代码，不论是别人的还是自己的，总是不可避免的。开始TDD，需要有勇气，而如果没有TDD就开始改代码，那就是鲁莽了。

令狐说得是：

其实所谓的“现代理论”未必比老的理论高明多少，对于一个人来说，重要的是他能不能把一种理论（无论是现代的还是古代的）变成自己有效的武器。一个掌握了一种有效武器的人，比掌握了无数新理论但不能有效运用的人要有用得多。

有效运用是最重要的事。