設計沒(méi)有標準，模式充滿(mǎn)變化，我們對設計與模式的探討，就是希望能從沒(méi)有標準的設計中體驗設計的樂(lè )趣，從充滿(mǎn)變化的模式中尋求問(wèn)題的解決之道。
我這里所謂“設計沒(méi)有標準”，其實(shí)并非沒(méi)有標準，現實(shí)是設計的標準實(shí)在太多了。我們都希望找到最好的設計方案，然而什么是最好，每個(gè)人都有自己的“哈姆雷特”。滿(mǎn)足客戶(hù)需求的設計就是最好的，這個(gè)結論我想不會(huì )有人反對，前提是，怎樣通過(guò)設計來(lái)滿(mǎn)足客戶(hù)需求？
計劃的設計和演進(jìn)的設計
通常來(lái)說(shuō)，軟件設計不外乎兩種方式：計劃的設計和演進(jìn)的設計。很多人看來(lái)，計劃的設計更符合工程學(xué)的理念。如果你要建一間茅屋，那么你只需夯好土墻，再胡亂堆放一些茅草置于屋頂之上就可以了。然而，如果要你建一座蘇州的拙政園，就必須事先有計劃的設計了。哪里應該堆放假山，哪里應該開(kāi)辟池塘，亭子的形狀，院落的分布，乃至于園內的一花一木，無(wú)不需要獨具匠心。軟件設計也是如此，且過(guò)之而無(wú)不及。接手項目的時(shí)候，首先考慮的不是編碼，而是考慮整個(gè)系統的架構，根據需求考慮系統中的重大問(wèn)題。模塊的功能，模塊間的關(guān)系和系統分布的層次，都需要匠心獨運，從一個(gè)抽象的層面來(lái)考慮。
演進(jìn)的設計恰好與之相反，它是一種漸進(jìn)的過(guò)程。它并不要求前期的設計有多么的完美，實(shí)現的需求有多么的完整，你只需要把現階段考慮的問(wèn)題編碼實(shí)現就可以了，隨著(zhù)演進(jìn)的深入，編碼也會(huì )隨之而修正，最后設計會(huì )逐漸豐滿(mǎn)起來(lái)，經(jīng)過(guò)一系列的方法，最后的設計也漸趨完美。
你也許會(huì )認為“演進(jìn)的設計”如此的簡(jiǎn)陋與平庸。沒(méi)有計劃，只會(huì )令設計一團遭。但我需要提醒你的是，雖然都是工程學(xué)，軟件的設計并沒(méi)有建筑設計那么簡(jiǎn)單。因為，你很難在設計之初，考慮到客戶(hù)的全部需求，甚至于實(shí)現未來(lái)的擴展。在設計一開(kāi)始，你能確信：
你對客戶(hù)的需求都理解了嗎？
你能確定客戶(hù)的需求不再變化嗎？
你設計的軟件架構真的能滿(mǎn)足需求嗎？
是的，你無(wú)法給出肯定的回答?？傊以谶@里不是想說(shuō)服每個(gè)人，要采取哪一種設計方式。事實(shí)上，我也面臨抉擇的困難。
過(guò)度設計，還是簡(jiǎn)單設計？
Kent在《解析極限編程——擁抱變化》中為簡(jiǎn)單系統制定了四個(gè)評價(jià)標準，依次為（最重要的排在最前面）：
通過(guò)所有測試；
體現所有意圖；
避免重復；
類(lèi)或者方法數量最少；
這些標準寫(xiě)出來(lái)簡(jiǎn)單，要根據這個(gè)標準來(lái)實(shí)現，就不是那么容易的事了。我相信，軟件設計人員都希望自己的設計盡可能簡(jiǎn)單。然而，在設計時(shí)，我們不僅僅要考慮軟件的功能，我們還要考慮軟件的性能、擴展性，模塊間的耦合關(guān)系，系統的穩定、部署和更新，版本的管理，系統的安全，界面的友好程度。要想簡(jiǎn)單，何其之難！
Do the simplest thing that could possibly work! 這是XP人士大聲疾呼的口號，我也舉雙手贊成。問(wèn)題是，我們需要讓簡(jiǎn)單的事情，同時(shí)又有效。很多人在設計時(shí)，并不滿(mǎn)足于實(shí)現眼前的功能?？吹郊臃?，他們可能還會(huì )想到乘法；雖然目前的需求是整數，他們可能想到今后可能會(huì )擴展到實(shí)數，甚至于復數。他們希望能利用某種設計，使其具有更好的擴展性。從眼前的需求來(lái)看，可能是過(guò)度設計；然后對于未來(lái)，這個(gè)設計才是最完美的方案。
問(wèn)題不在于設計是否過(guò)度，關(guān)鍵還是在于設計的理念。是只做目前需要的事，還是未雨綢繆，想好今后的功能擴展？這個(gè)問(wèn)題的答案還需要實(shí)際的項目開(kāi)發(fā)來(lái)檢驗，根據不同的需求，答案會(huì )因此而異。
需要設計模式嗎？
答案是肯定的，但你需要確定的是模式的應用是否過(guò)度？我得承認，世界上有很多天才的程序員，他可以在一段代碼中包含6種設計模式，也可以不用模式而把設計做得很好。但我們的目標是追求有效的設計，而設計模式可以為這個(gè)目標提供某種參考模型、設計方法。我們不需要奉GOF的設計模式為圭臬，但合理的運用設計模式，才是正確的抉擇。
很多人看過(guò)GOF的《Design Patterns》，對這23種模式也背得滾瓜爛熟。但重要的不是你熟記了多少個(gè)模式的名稱(chēng)，關(guān)鍵還在于付諸實(shí)踐的運用。為了有效地設計，而去熟悉某種模式所花費的代價(jià)是值得的，因為很快你會(huì )在設計中發(fā)現這種模式真的很好，很多時(shí)候它令得你的設計更加簡(jiǎn)單了。
其實(shí)在軟件設計人員中，唾棄設計模式的可能很少，盲目夸大設計模式功用的反而更多。言必談“模式”，并不能使你成為優(yōu)秀的架構師。真正出色的設計師，懂得判斷運用模式的時(shí)機。
還有一個(gè)問(wèn)題是，很多才踏入軟件設計領(lǐng)域的人員，往往對設計模式很困惑。對于他們來(lái)說(shuō)，由于沒(méi)有項目的實(shí)際經(jīng)驗，OO的思想也還未曾建立，設計模式未免過(guò)于高深了。其實(shí)，即使是非常有經(jīng)驗的程序員，也不敢夸口對各種模式都能合理應用。
重構是必然的！
既然我們無(wú)法給出一個(gè)完美的設計方案，因為客戶(hù)的需求總是變化的，重構也就成為必然。問(wèn)題是，這樣沒(méi)有添加任何功能的重構，你是否愿意為此付出精力、時(shí)間去完成。當客戶(hù)要求的Deadline將要到來(lái)的時(shí)候，你還認為你的重構工作是必要的嗎？
有時(shí)候，軟件設計常常身不由己。然而，純從技術(shù)的角度來(lái)看，重構非但必然，而且重要。既然我們都明白，復雜的未嘗就是好的，簡(jiǎn)單的也不一定是容易的。要保持你的設計盡可能的簡(jiǎn)單，可能你還需要時(shí)時(shí)借助重構的利器，來(lái)“改善你既有代碼的設計”。
對于重構，Martin Fowler給出了很多條款。這些條款并不是政治課本的教條，也不是“日月神教”的神奇咒語(yǔ)，念著(zhù)它們就可以防身。這些條款確實(shí)很重要，但你需要的是學(xué)會(huì )他后，然后忘記他，就象張無(wú)忌學(xué)太極拳那樣。我不是故弄玄虛，事實(shí)上只有這樣，重構的精神才能完全融入到你的設計中。
UML重要嗎？
我現在看一個(gè)設計方案的時(shí)候，更希望先看看UML圖，然后再看文檔的實(shí)際描述。如果讓我讀一段代碼，我希望能先看看類(lèi)圖，或許更容易理解代碼的含義。UML在OO世界里像是世界語(yǔ)，它便于程序員間的交流，讓別人更容易理解你的意圖。同時(shí)，在設計UML圖的過(guò)程中，也是一種對思路的清理，對客戶(hù)需求的把握，設計思想的跟蹤。
UML是一種基于對象的統一建模語(yǔ)言，它能夠為系統設計提供清晰直觀(guān)的設計。在面向對象世界里，UML的地位彌足輕重，甚至被稱(chēng)為是軟件設計的一場(chǎng)革命。對于有計劃的設計，UML的價(jià)值就體現得淋漓盡致。如果我們要清晰地表現模塊的功能，模塊間的關(guān)系和系統分布的層次，使用UML可以使設計師減少很多麻煩，同時(shí)降低了語(yǔ)義描述的二義性。然而，如果我們在做演進(jìn)的設計時(shí)，UML還有那么重要嗎？我們只需要對眼前的需求進(jìn)行編碼、測試，然后重構?？赡芪覀冎恍枰赑air Team中討論設計方案，在預定技術(shù)框架內探討實(shí)現的可能和細節。我們完全可以?huà)侀_(kāi)UML繁瑣而死板的設計，畢竟最能忠實(shí)體現設計思想的，不是文檔，不是用例圖或是什么類(lèi)圖，而是代碼。
那么，有多少人是這樣想的？
TDD、單元測試和其他
軟件的生命是什么，是質(zhì)量！而保證質(zhì)量的唯一方法，就是測試。傳統的軟件開(kāi)發(fā)過(guò)程，強調首先進(jìn)行需求分析，再從需求分析中抽象出概要設計，進(jìn)而作出詳細設計，然后編碼，最后才是測試以驗證代碼的正確性。而測試驅動(dòng)開(kāi)發(fā)（TDD）改變了編碼的過(guò)程，開(kāi)發(fā)僅僅包括三方面的活動(dòng)：編寫(xiě)測試用例，編碼并進(jìn)行測試，重構代碼以消除重復代碼使其更簡(jiǎn)單、更靈活、更容易理解。通過(guò)測試來(lái)驅動(dòng)開(kāi)發(fā)，聽(tīng)起來(lái)是那么的離經(jīng)叛道，然而實(shí)施起來(lái)，又是那么合理、正確和簡(jiǎn)單，前提是：我們不能在一開(kāi)始就獲得正確的設計！TDD避免了對不完整需求造成的不成熟的設計。通過(guò)單元測試，保證了代碼的正確性與高質(zhì)量；通過(guò)重構，使設計更加簡(jiǎn)單、靈活。
