canonical

     Agile批評(píng)過(guò)度設(shè)計(jì)(over-engineering)的聲音很大，但對(duì)于設(shè)計(jì)不足(under-engineering)同樣是持堅(jiān)決的否定態(tài)度 的。修改過(guò)度設(shè)計(jì)的應(yīng)用比修改設(shè)計(jì)不足的程序要容易的多。因?yàn)楹?jiǎn)化的途徑是明確的，而走向復(fù)雜的途徑卻往往是難以控制的。Refactoring To Patterns試圖引入一些經(jīng)驗(yàn)，但這些可預(yù)見(jiàn)的調(diào)整多半只在細(xì)節(jié)處，其影響是局部的。一個(gè)復(fù)雜性低層次的設(shè)計(jì)要支持一個(gè)復(fù)雜性高的應(yīng)用，所需的代碼量 不是線(xiàn)性的堆砌，而是幾何級(jí)數(shù)式的增長(zhǎng)，重構(gòu)的時(shí)候需要做出的改變往往也是影響全局的。而事實(shí)上，設(shè)計(jì)不足是比過(guò)度設(shè)計(jì)更加常見(jiàn)的情況。真實(shí)的情況也許 是，在真正需要我們做出創(chuàng)造性設(shè)計(jì)的地方我們因?yàn)闊o(wú)知和無(wú)能而設(shè)計(jì)不足，而在那些渴求簡(jiǎn)單的地方，我們卻自詡為先知而加上很多華麗的設(shè)計(jì)來(lái)維護(hù)虛幻的可擴(kuò) 展性。這里的度是很難把握的。高段位的棋手可以比低段位的棋手預(yù)見(jiàn)到更多的步數(shù)，而一個(gè)優(yōu)秀的軟件架構(gòu)師也需要比普通的程序員更早的預(yù)見(jiàn)到系統(tǒng)發(fā)展的障 礙。在我們明確可預(yù)見(jiàn)的范圍內(nèi)，當(dāng)然是要把所有的設(shè)計(jì)做好，而在我們思維的邊界處，"行"就變得比"思"重要了。
    大談"over-engineering"的主多半都有著豐富的過(guò)度設(shè)計(jì)的經(jīng)驗(yàn)，千萬(wàn)不要把他們回顧時(shí)的話(huà)語(yǔ)當(dāng)成是普遍的真理。所謂大巧若拙，精煉的小詩(shī) 可比長(zhǎng)篇大論難寫(xiě)的多了。有時(shí)采用一種簡(jiǎn)單的處理方式，是因?yàn)槲覀兏杏X(jué)到它不會(huì)成為障礙，雖然此時(shí)并沒(méi)有明確的設(shè)計(jì)過(guò)程。你必須有能力進(jìn)行過(guò)度設(shè)計(jì)，才能 真正理解簡(jiǎn)單設(shè)計(jì)的精妙之處