从前,有位咨询顾问参访一个幵发项目。系统核心是个class hierarchies (类阶层体系〉，顾问看了开发人员所写的一些代码。他发现整个体系相当凌乱，上层classes对于classes的运作做了一些假设，下层（继承〕classes实现这些假设。但是这些假设并不适合所有subclasses，导致覆写〔overridden）行为非常繁重。只要在superclass做点修改，就可以减少许多覆写必要。在另一些地方，superclass的某些意图并未被良好理解，因此其中某些行为在subclasses内重复出现。还有一些地方，好几个subclasses做相同的事情，其实可以把它们搬到class hierarchy的上层去做。
这位顾问于是建议项目经理看看这些代码，把它们整理一下，但是经理并不热衷于此，毕竟程序看上去还可以运行，而且项目面临很大的进度压力。于是经理说，晚些时候再抽时间做这些整理工作。
顾问也把他的想法告诉了在这个class hierarchy上工作的程序员，告诉他们可能发生的事情。程序员都很敏锐，马上就看出问题的严重性。他们知道这并不全是他们 的错，有时候的确需要借助外力才能发现问题。程序员立刻用了一两天的时间整理好这个class hierarchy，并删掉了其中一半代码，功能毫发无损。他们对此十分满意， 而且发现系统速度变得更快，更容易加入新classws或使用其他classes。
项目经理并不高兴。进度排得很紧，许多工作要做。系统必须在几个月之后发布，许多功能还等着加进去，这些程序员却白白耗费两天时间，什么活儿都没干。原先的代码运行起来还算正常，他们的新设计显然有点过于「理论」且过于「无瑕」。项目要出货给客户的，是可以有效运行的代码，不是用以取悦学究们的完美东西。顾问接下来又建议应该在系统的其他核心部分进行这样的整理工作，这会使整个项目停顿一至二个星期。所有这些工作只是为了让代码看起来更漂亮，并不能给系统添加任何新功能。
你对这个故事有什么看法？你认为这个顾问的建议（更进一步整理程序〉是对的吗？你会因循那句古老的工程谚语吗：「如果它还可以运行，就不要动它」。
六个月之后这个项目宣告失败，很大的原因是代码太复杂，无法除错，也无法获得可被接受的性能。
后来，项目重新启动最终成功。项目几乎从头开始编写整个系统，新顾问做了几件迥异以往的事，其中最重要的一件就是坚持以持续不断的重构行为来整理代码。
评论