設(shè)計(jì)沒有標(biāo)準(zhǔn)，模式充滿變化，我們對(duì)設(shè)計(jì)與模式的探討，就是希望能從沒有標(biāo)準(zhǔn)的設(shè)計(jì)中體驗(yàn)設(shè)計(jì)的樂趣，從充滿變化的模式中尋求問題的解決之道。

我這里所謂“設(shè)計(jì)沒有標(biāo)準(zhǔn)”，其實(shí)并非沒有標(biāo)準(zhǔn)，現(xiàn)實(shí)是設(shè)計(jì)的標(biāo)準(zhǔn)實(shí)在太多了。我們都希望找到最好的設(shè)計(jì)方案，然而什么是最好，每個(gè)人都有自己的“哈姆雷特”。滿足客戶需求的設(shè)計(jì)就是最好的，這個(gè)結(jié)論我想不會(huì)有人反對(duì)，前提是，怎樣通過設(shè)計(jì)來滿足客戶需求？

計(jì)劃的設(shè)計(jì)和演進(jìn)的設(shè)計(jì)

通常來說，軟件設(shè)計(jì)不外乎兩種方式：計(jì)劃的設(shè)計(jì)和演進(jìn)的設(shè)計(jì)。很多人看來，計(jì)劃的設(shè)計(jì)更符合工程學(xué)的理念。如果你要建一間茅屋，那么你只需夯好土墻，再胡亂堆放一些茅草置于屋頂之上就可以了。然而，如果要你建一座蘇州的拙政園，就必須事先有計(jì)劃的設(shè)計(jì)了。哪里應(yīng)該堆放假山，哪里應(yīng)該開辟池塘，亭子的形狀，院落的分布，乃至于園內(nèi)的一花一木，無不需要獨(dú)具匠心。軟件設(shè)計(jì)也是如此，且過之而無不及。接手項(xiàng)目的時(shí)候，首先考慮的不是編碼，而是考慮整個(gè)系統(tǒng)的架構(gòu)，根據(jù)需求考慮系統(tǒng)中的重大問題。模塊的功能，模塊間的關(guān)系和系統(tǒng)分布的層次，都需要匠心獨(dú)運(yùn)，從一個(gè)抽象的層面來考慮。

演進(jìn)的設(shè)計(jì)恰好與之相反，它是一種漸進(jìn)的過程。它并不要求前期的設(shè)計(jì)有多么的完美，實(shí)現(xiàn)的需求有多么的完整，你只需要把現(xiàn)階段考慮的問題編碼實(shí)現(xiàn)就可以了，隨著演進(jìn)的深入，編碼也會(huì)隨之而修正，最后設(shè)計(jì)會(huì)逐漸豐滿起來，經(jīng)過一系列的方法，最后的設(shè)計(jì)也漸趨完美。

你也許會(huì)認(rèn)為“演進(jìn)的設(shè)計(jì)”如此的簡(jiǎn)陋與平庸。沒有計(jì)劃，只會(huì)令設(shè)計(jì)一團(tuán)遭。但我需要提醒你的是，雖然都是工程學(xué)，軟件的設(shè)計(jì)并沒有建筑設(shè)計(jì)那么簡(jiǎn)單。因?yàn)?，你很難在設(shè)計(jì)之初，考慮到客戶的全部需求，甚至于實(shí)現(xiàn)未來的擴(kuò)展。在設(shè)計(jì)一開始，你能確信：
你對(duì)客戶的需求都理解了嗎？
你能確定客戶的需求不再變化嗎？
你設(shè)計(jì)的軟件架構(gòu)真的能滿足需求嗎？

是的，你無法給出肯定的回答。總之我在這里不是想說服每個(gè)人，要采取哪一種設(shè)計(jì)方式。事實(shí)上，我也面臨抉擇的困難。

過度設(shè)計(jì)，還是簡(jiǎn)單設(shè)計(jì)？

Kent在《解析極限編程——擁抱變化》中為簡(jiǎn)單系統(tǒng)制定了四個(gè)評(píng)價(jià)標(biāo)準(zhǔn)，依次為（最重要的排在最前面）：
通過所有測(cè)試；
體現(xiàn)所有意圖；
避免重復(fù)；
類或者方法數(shù)量最少；

這些標(biāo)準(zhǔn)寫出來簡(jiǎn)單，要根據(jù)這個(gè)標(biāo)準(zhǔn)來實(shí)現(xiàn)，就不是那么容易的事了。我相信，軟件設(shè)計(jì)人員都希望自己的設(shè)計(jì)盡可能簡(jiǎn)單。然而，在設(shè)計(jì)時(shí)，我們不僅僅要考慮軟件的功能，我們還要考慮軟件的性能、擴(kuò)展性，模塊間的耦合關(guān)系，系統(tǒng)的穩(wěn)定、部署和更新，版本的管理，系統(tǒng)的安全，界面的友好程度。要想簡(jiǎn)單，何其之難！

Do the simplest thing that could possibly work! 這是XP人士大聲疾呼的口號(hào)，我也舉雙手贊成。問題是，我們需要讓簡(jiǎn)單的事情，同時(shí)又有效。很多人在設(shè)計(jì)時(shí)，并不滿足于實(shí)現(xiàn)眼前的功能?？吹郊臃?，他們可能還會(huì)想到乘法；雖然目前的需求是整數(shù)，他們可能想到今后可能會(huì)擴(kuò)展到實(shí)數(shù)，甚至于復(fù)數(shù)。他們希望能利用某種設(shè)計(jì)，使其具有更好的擴(kuò)展性。從眼前的需求來看，可能是過度設(shè)計(jì)；然后對(duì)于未來，這個(gè)設(shè)計(jì)才是最完美的方案。

問題不在于設(shè)計(jì)是否過度，關(guān)鍵還是在于設(shè)計(jì)的理念。是只做目前需要的事，還是未雨綢繆，想好今后的功能擴(kuò)展？這個(gè)問題的答案還需要實(shí)際的項(xiàng)目開發(fā)來檢驗(yàn)，根據(jù)不同的需求，答案會(huì)因此而異。

需要設(shè)計(jì)模式嗎？

答案是肯定的，但你需要確定的是模式的應(yīng)用是否過度？我得承認(rèn)，世界上有很多天才的程序員，他可以在一段代碼中包含6種設(shè)計(jì)模式，也可以不用模式而把設(shè)計(jì)做得很好。但我們的目標(biāo)是追求有效的設(shè)計(jì)，而設(shè)計(jì)模式可以為這個(gè)目標(biāo)提供某種參考模型、設(shè)計(jì)方法。我們不需要奉GOF的設(shè)計(jì)模式為圭臬，但合理的運(yùn)用設(shè)計(jì)模式，才是正確的抉擇。

很多人看過GOF的《Design Patterns》，對(duì)這23種模式也背得滾瓜爛熟。但重要的不是你熟記了多少個(gè)模式的名稱，關(guān)鍵還在于付諸實(shí)踐的運(yùn)用。為了有效地設(shè)計(jì)，而去熟悉某種模式所花費(fèi)的代價(jià)是值得的，因?yàn)楹芸炷銜?huì)在設(shè)計(jì)中發(fā)現(xiàn)這種模式真的很好，很多時(shí)候它令得你的設(shè)計(jì)更加簡(jiǎn)單了。

其實(shí)在軟件設(shè)計(jì)人員中，唾棄設(shè)計(jì)模式的可能很少，盲目夸大設(shè)計(jì)模式功用的反而更多。言必談“模式”，并不能使你成為優(yōu)秀的架構(gòu)師。真正出色的設(shè)計(jì)師，懂得判斷運(yùn)用模式的時(shí)機(jī)。

還有一個(gè)問題是，很多才踏入軟件設(shè)計(jì)領(lǐng)域的人員，往往對(duì)設(shè)計(jì)模式很困惑。對(duì)于他們來說，由于沒有項(xiàng)目的實(shí)際經(jīng)驗(yàn)，OO的思想也還未曾建立，設(shè)計(jì)模式未免過于高深了。其實(shí)，即使是非常有經(jīng)驗(yàn)的程序員，也不敢夸口對(duì)各種模式都能合理應(yīng)用。

重構(gòu)是必然的！

既然我們無法給出一個(gè)完美的設(shè)計(jì)方案，因?yàn)榭蛻舻男枨罂偸亲兓模貥?gòu)也就成為必然。問題是，這樣沒有添加任何功能的重構(gòu)，你是否愿意為此付出精力、時(shí)間去完成。當(dāng)客戶要求的Deadline將要到來的時(shí)候，你還認(rèn)為你的重構(gòu)工作是必要的嗎？

有時(shí)候，軟件設(shè)計(jì)常常身不由己。然而，純從技術(shù)的角度來看，重構(gòu)非但必然，而且重要。既然我們都明白，復(fù)雜的未嘗就是好的，簡(jiǎn)單的也不一定是容易的。要保持你的設(shè)計(jì)盡可能的簡(jiǎn)單，可能你還需要時(shí)時(shí)借助重構(gòu)的利器，來“改善你既有代碼的設(shè)計(jì)”。

對(duì)于重構(gòu)，Martin Fowler給出了很多條款。這些條款并不是政治課本的教條，也不是“日月神教”的神奇咒語(yǔ)，念著它們就可以防身。這些條款確實(shí)很重要，但你需要的是學(xué)會(huì)他后，然后忘記他，就象張無忌學(xué)太極拳那樣。我不是故弄玄虛，事實(shí)上只有這樣，重構(gòu)的精神才能完全融入到你的設(shè)計(jì)中。

UML重要嗎？

我現(xiàn)在看一個(gè)設(shè)計(jì)方案的時(shí)候，更希望先看看UML圖，然后再看文檔的實(shí)際描述。如果讓我讀一段代碼，我希望能先看看類圖，或許更容易理解代碼的含義。UML在OO世界里像是世界語(yǔ)，它便于程序員間的交流，讓別人更容易理解你的意圖。同時(shí)，在設(shè)計(jì)UML圖的過程中，也是一種對(duì)思路的清理，對(duì)客戶需求的把握，設(shè)計(jì)思想的跟蹤。

UML是一種基于對(duì)象的統(tǒng)一建模語(yǔ)言，它能夠?yàn)橄到y(tǒng)設(shè)計(jì)提供清晰直觀的設(shè)計(jì)。在面向?qū)ο笫澜缋铮琔ML的地位彌足輕重，甚至被稱為是軟件設(shè)計(jì)的一場(chǎng)革命。對(duì)于有計(jì)劃的設(shè)計(jì)，UML的價(jià)值就體現(xiàn)得淋漓盡致。如果我們要清晰地表現(xiàn)模塊的功能，模塊間的關(guān)系和系統(tǒng)分布的層次，使用UML可以使設(shè)計(jì)師減少很多麻煩，同時(shí)降低了語(yǔ)義描述的二義性。然而，如果我們?cè)谧鲅葸M(jìn)的設(shè)計(jì)時(shí)，UML還有那么重要嗎？我們只需要對(duì)眼前的需求進(jìn)行編碼、測(cè)試，然后重構(gòu)?？赡芪覀冎恍枰赑air Team中討論設(shè)計(jì)方案，在預(yù)定技術(shù)框架內(nèi)探討實(shí)現(xiàn)的可能和細(xì)節(jié)。我們完全可以拋開UML繁瑣而死板的設(shè)計(jì)，畢竟最能忠實(shí)體現(xiàn)設(shè)計(jì)思想的，不是文檔，不是用例圖或是什么類圖，而是代碼。

那么，有多少人是這樣想的？

TDD、單元測(cè)試和其他

軟件的生命是什么，是質(zhì)量！而保證質(zhì)量的唯一方法，就是測(cè)試。傳統(tǒng)的軟件開發(fā)過程，強(qiáng)調(diào)首先進(jìn)行需求分析，再?gòu)男枨蠓治鲋谐橄蟪龈乓O(shè)計(jì)，進(jìn)而作出詳細(xì)設(shè)計(jì)，然后編碼，最后才是測(cè)試以驗(yàn)證代碼的正確性。而測(cè)試驅(qū)動(dòng)開發(fā)（TDD）改變了編碼的過程，開發(fā)僅僅包括三方面的活動(dòng)：編寫測(cè)試用例，編碼并進(jìn)行測(cè)試，重構(gòu)代碼以消除重復(fù)代碼使其更簡(jiǎn)單、更靈活、更容易理解。通過測(cè)試來驅(qū)動(dòng)開發(fā)，聽起來是那么的離經(jīng)叛道，然而實(shí)施起來，又是那么合理、正確和簡(jiǎn)單，前提是：我們不能在一開始就獲得正確的設(shè)計(jì)！TDD避免了對(duì)不完整需求造成的不成熟的設(shè)計(jì)。通過單元測(cè)試，保證了代碼的正確性與高質(zhì)量；通過重構(gòu)，使設(shè)計(jì)更加簡(jiǎn)單、靈活。