就像这样差不多，不过用的是COBOL语言。

别再烂泥上堆砌新功能了，直接把浴缸拆掉吧。

我在一家大公司工作，专门负责处理那些几十年前的COBOL系统。

我在90年代中期就开始做这个了，当那时我转回到做COBOL相关的工作时。当时我主要是做新开发，所以那个时候不像现在，我并没有那么多旧代码要处理。

我的下一个COBOL工作是在一系列公司里，这些公司既有需要维护的老系统，也需要新的开发。我在一家糖果厂编写了IMS/DB程序，还在索尼写过维修追踪和库存控制，那段经历很有趣。

我在任何项目中都会花很大一部分时间来理解之前的开发人员做了什么，以及这如何影响我当前的任务和整个程序。

我注意到一件事：在添加新功能的同时，删除旧代码会让很多人感到极度抗拒，甚至是恐惧。

这种态度让我想起了某种品牌的浴室改造。与其移除旧的、发霉的浴缸并进行彻底翻新，你只是在上面套上一层闪亮的塑料壳。虽然看起来像是新的，但下面的腐烂依旧存在。管道依旧糟糕，霉菌依然滋生。

在COBOL系统中，我们经常做同样的事情——只是在旧代码逻辑之上叠加新代码，不敢深入探究底层。

我曾经参与过一个程序，该程序将蜂窝交换机数据从第1版到第8版转换成我们的内部格式。现有代码支持第1版到第8版的数据转换。

我们多年来都没有使用那些版本了。新的交换机已经升级到了版本10。所以我做了显而易见的事情：把旧的支持代码删掉了，只为版本10重新编写了代码。结果是程序变得更简洁易维护了——现在程序的规模只有以前的一小部分了。

然后我的经理让我重新支持旧版本的功能，我基本上没答应。

没有任何情况下我们会回退到旧版交换机软件。他同意——理论上讲。但他不太愿意舍弃那些旧代码，尽管他说不出个所以然来。

最后，我们达成了协议：如果我们真得回去，我会加班把它恢复。（我们也没回去过。）

有时这种做法在机构中根深蒂固，即使每个人都能承认这些代码已经过时了。

而且让我们明确一点：过时的代码不仅不会无害地呆在角落里，它会阻碍开发。它会增加维护的复杂性。它会增加编译时间。它会增加回归的可能性。它让系统更难理解。

为什么冗余代码仍然存在

经过多年剥离遗留代码并与同事和上司讨论之后，我发现了三个原因，解释了企业系统中为何会有这么多无用代码：

理解他人的代码实际上很难。试图理解另一个开发者的代码逻辑，尤其是在处理COBOL代码时，绝非易事，特别是对于COBOL这样的语言。但详尽且准确的文档却难得一见。

即使我想整理某件事，也不总是有时间。有截止日期要赶，还要提交成果。我知道我将来可能还得再处理这个烂摊子，但现在只能先将就一下，往后推。

风险就是恐惧。

因为我快速修复导致程序80%的部分发生变化，我被迫参加了数不胜数的会议。

“为什么代码变更监控器标记了这么多代码？”

“因为我改了其中的80%。”

“但是为什么？”

“因为它太糟糕了。原来的程序员潦草拼凑，还有十多个其他人又把它弄糟了。它需要彻底重构。”

“但是如果它坏了呢？”

“我会搞定。”

我从来没有后悔过做一次大的重写。当然，在这30多年中，我也犯了不少错误。但总的来说，每一次重构都让我觉得是值得的。

企业系统中充斥着“外表光鲜”的代码——新功能下掩盖着多年的老旧代码。

我们保留这段代码不是因为它有用，而是因为它 感觉 起来很安全。到目前为止，它依然存在。它还没有 出毛病。删除它感觉既麻烦又冒险，让人不自在。

但是这种恐惧是有代价的。每一行过时的代码都增加了复杂性，增加了维护成本，减少了清晰度，并增加了风险。

• 承认遗留代码并非不可更改。 如果它不再有效（或不再有效地工作），就去掉它。
• 将大规模重构正常化。 停止将它视为红旗——将其视为预防性保养。
• 接受风险是进步的一部分。 仔细测试，记录你的更改，并继续前进。
• 不要在烂基础上建楼。 不要修补坏系统。 重建它们。
• 信任正在工作的人。 如果一个开发人员说某些部分需要被拆掉，相信他们。

在这一行干了三十年后，我可以肯定地说：

每次我修复并重建一个糟糕的COBOL（一种古老的编程语言）程序时，都让我受益。

我引入了错误，我两次重写了代码。但从未后悔过，真希望我当时没动它。