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

主要問題出在開發(fā)商的設(shè)計和技術(shù)方面（我們暫時先不管Weinberg準(zhǔn)則。“No matter what they tell you, it's always a people problem”）。開發(fā)商認(rèn)為可以借此機會開發(fā)一個可以通用的軟件系統(tǒng)， 而且他們認(rèn)為可以在顧客的預(yù)算之內(nèi)開發(fā)完這個系統(tǒng)。

這些想法就導(dǎo)致了經(jīng)典的“框架迷戀癥”。開發(fā)商不再試著去解決顧客的問題，而是試著去解決所有他們認(rèn)為是問題的問題。因此， 單獨就那個原因而言，就可能比預(yù)期花費10倍甚至更多的時間和金錢

當(dāng)然， 我們不可能總是避免人的問題。而且他們設(shè)計的體系架構(gòu)本來就有很多重大的缺陷。其中一個缺陷是因為對需求的誤解和假設(shè)， 并且將對象實體和Windows消息混雜在一起了。這些問題的出現(xiàn)是因為有一個技術(shù)主管， 他是這個系統(tǒng)的架構(gòu)師。 他強迫人們認(rèn)可他的設(shè)計， 并且吵了那些有異議的人員的魷魚。因此， 他對這個項目的誤解就和他對這個項目理解的一樣多， 也就是說， 他什么也不理解。

一般來說，“框架迷戀癥”只是其中一種方式， 也可能是最高效的方式， 使企圖重用的代碼失效。

我認(rèn)為當(dāng)有些人決定我們應(yīng)該重用某些代碼的時候， 然而實際上火候還沒有到。這種企圖就可能導(dǎo)致重用代碼的意圖失去意義了。也就是說，我們的開發(fā)不是按照需求驅(qū)動了，而是由開發(fā)者的意圖驅(qū)動了。我個人問題當(dāng)我們第二次意識到需要重用某些代碼的時候， 可能才是真正需要重用的時候。通常總是那些我無法預(yù)料到的情況， 至少是它沒有發(fā)生在我認(rèn)為應(yīng)該發(fā)生的時候。

另外一個著名的代碼重用失敗的例子， 對整個工業(yè)界都是如此， 而且難以置信的昂貴就是EJB1和EJB2（EJB3好像就完全不同了）。EJB1/2是被設(shè)計用來處理一個想像中的開發(fā)過程， 但是看起來似乎從來沒有在EJB1/2的生命周期內(nèi)發(fā)生過。因此開發(fā)人員一直沒有從使用這個框架中受益，反而一直出在和它的斗爭之中。而且我也聽到過很多企業(yè)將EJB踢出他們系統(tǒng)中的例子。普遍都說， 代價太大了。

我認(rèn)為一些庫也有可能陷入這種境地。當(dāng)想著如何做才能使一個庫被盡可能多的重用而不是如何去重用一個庫的時候， 可能問題就來了。Python中的大多數(shù)庫，在我看來， 在實際應(yīng)用已經(jīng)相當(dāng)成功，而且很穩(wěn)定。一個例外就是xmllib庫，我認(rèn)為太缺少Python的風(fēng)格了。Python2.5中似乎已經(jīng)解決這個問題了。

?

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