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

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

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

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

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

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

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

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

?

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