When Reuse Goes Bad

几年前， 我作为一个顾问， 着手处理一个已经快要失败的项目了。顾客和开发商签订的合约是在一年之内开发完那个项目。 当我被叫过去的时候， 时间已经过去一年了。 显而易见， 这个项目失败了。

主要问题出在开发商的设计和技术方面（我们暂时先不管Weinberg准则。“No matter what they tell you, it's always a people problem”）。开发商认为可以借此机会开发一个可以通用的软件系统， 而且他们认为可以在顾客的预算之内开发完这个系统。

这些想法就导致了经典的“框架迷恋症”。开发商不再试着去解决顾客的问题，而是试着去解决所有他们认为是问题的问题。因此， 单独就那个原因而言，就可能比预期花费10倍甚至更多的时间和金钱

当然， 我们不可能总是避免人的问题。而且他们设计的体系架构本来就有很多重大的缺陷。其中一个缺陷是因为对需求的误解和假设， 并且将对象实体和Windows消息混杂在一起了。这些问题的出现是因为有一个技术主管， 他是这个系统的架构师。 他强迫人们认可他的设计， 并且吵了那些有异议的人员的鱿鱼。因此， 他对这个项目的误解就和他对这个项目理解的一样多， 也就是说， 他什么也不理解。

一般来说，“框架迷恋症”只是其中一种方式， 也可能是最高效的方式， 使企图重用的代码失效。

我认为当有些人决定我们应该重用某些代码的时候， 然而实际上火候还没有到。这种企图就可能导致重用代码的意图失去意义了。也就是说，我们的开发不是按照需求驱动了，而是由开发者的意图驱动了。我个人问题当我们第二次意识到需要重用某些代码的时候， 可能才是真正需要重用的时候。通常总是那些我无法预料到的情况， 至少是它没有发生在我认为应该发生的时候。

另外一个著名的代码重用失败的例子， 对整个工业界都是如此， 而且难以置信的昂贵就是EJB1和EJB2（EJB3好像就完全不同了）。EJB1/2是被设计用来处理一个想像中的开发过程， 但是看起来似乎从来没有在EJB1/2的生命周期内发生过。因此开发人员一直没有从使用这个框架中受益，反而一直出在和它的斗争之中。而且我也听到过很多企业将EJB踢出他们系统中的例子。普遍都说， 代价太大了。

我认为一些库也有可能陷入这种境地。当想着如何做才能使一个库被尽可能多的重用而不是如何去重用一个库的时候， 可能问题就来了。Python中的大多数库，在我看来， 在实际应用已经相当成功，而且很稳定。一个例外就是xmllib库，我认为太缺少Python的风格了。Python2.5中似乎已经解决这个问题了。