幾年前， 我作為一個顧問， 著手處理一個已經快要失敗的項目了。顧客和開發商簽訂的合約是在一年之內開發完那個項目。 當我被叫過去的時候， 時間已經過去一年了。 顯而易見， 這個項目失敗了。

主要問題出在開發商的設計和技術方面（我們暫時先不管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中似乎已經解決這個問題了。

?

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1472960