XP非常強(qiáng)調(diào)簡(jiǎn)單的設(shè)計(jì)原則：能夠用數(shù)組實(shí)現(xiàn)的功能決不用鏈表。在其它Agile方法中，簡(jiǎn)單的原則也被反復(fù)的強(qiáng)調(diào)。在這篇文章，我們就對(duì)簡(jiǎn)單性做一個(gè)全面的了解。
架構(gòu)應(yīng)該設(shè)計(jì)到什么程度？
軟件的架構(gòu)都是非常的復(fù)雜的，帶有大量的文檔和圖表。開發(fā)人員花在理解架構(gòu)本身上的時(shí)間甚至超出了實(shí)現(xiàn)架構(gòu)的時(shí)間。在前面的文章中，我們提到了一些反對(duì)象牙塔式架構(gòu)的一個(gè)原因，而其中的一個(gè)原因就是象牙塔式架構(gòu)的設(shè)計(jì)者往往在設(shè)計(jì)時(shí)參雜進(jìn)過多的自身經(jīng)驗(yàn)，而不是嚴(yán)格的按照需求來進(jìn)行設(shè)計(jì)。
在軟件開發(fā)領(lǐng)域，最為常見的設(shè)計(jì)就是"Code and Fix"方式的設(shè)計(jì)，設(shè)計(jì)隨著軟件開發(fā)過程而增長(zhǎng)。或者，我們可以認(rèn)為這種方式根本就不能算是設(shè)計(jì)，它抱著一種船到橋頭自然直的態(tài)度，可是在設(shè)計(jì)不斷改動(dòng)之后，代碼變得臃腫且難以理解，到處充滿著重復(fù)的代碼。這樣的情形下，架構(gòu)的設(shè)計(jì)也就無從談起，軟件就像是在風(fēng)雨中的破屋，瀕臨倒塌。
針對(duì)于這種情形，新的設(shè)計(jì)方式又出現(xiàn)了，Martin Fowler稱這種方式為"Planned Design"。和建筑的設(shè)計(jì)類似，它強(qiáng)調(diào)在編碼之前進(jìn)行嚴(yán)格的設(shè)計(jì)。這也就是我們?cè)趫F(tuán)隊(duì)設(shè)計(jì)中談到的架構(gòu)設(shè)計(jì)師的典型做法。設(shè)計(jì)師們通常不會(huì)去編程，理由是在土木工程中，你不可能看到一位設(shè)計(jì)師還要砌磚頭。
"Planned Design"較之"Code and Fix"進(jìn)步了許多，但是還是會(huì)存在很多問題。除了在團(tuán)隊(duì)設(shè)計(jì)中我們談的問題之外，需求變更將會(huì)導(dǎo)致更大的麻煩。因此，我們理所當(dāng)然的想到進(jìn)行"彈性設(shè)計(jì)"：彈性的設(shè)計(jì)能夠滿足需求的變更。而彈性的設(shè)計(jì)所付出的代價(jià)就是復(fù)雜的設(shè)計(jì)。
題外話：
這里我們談?wù)?Planned Design"引出的一些問題，并沒有任何排斥這種方式的意思。"Planned Design"還是有很多可取之處的，但也有很多需要改進(jìn)的地方。事實(shí)上，本文中我們討論的架構(gòu)設(shè)計(jì)方式，本質(zhì)上也是屬于"Planned Design"方式。和"Planned Design"相對(duì)應(yīng)的方式是XP所主張的"Evolutionary Design"方式，但是這種方式還有待于實(shí)踐的檢驗(yàn)，并不能簡(jiǎn)單的說他就一定要比"Planned Design"先進(jìn)或落后。但可以肯定的一點(diǎn)是："Evolutionary Design"方式中有很多的思想和技巧是值得"Planned Design"借鑒的。
解決方法：
XP中有兩個(gè)非常響亮的口號(hào)："Do The Simplest Thing that Could Possibly Work"和"You Aren't Going to Need It"（通常稱之為YAGNI）。他們的核心思想就是不要為了考慮將來，把目前并不需要的功能加到軟件中來。
粗看之下，會(huì)有很多開發(fā)人員認(rèn)為這是不切實(shí)際的口號(hào)。我能理解這種想法，其實(shí)，在我熱衷于模式、可重用組件技術(shù)的時(shí)候，我對(duì)XP提倡的簡(jiǎn)單的口號(hào)嗤之以鼻。但在實(shí)際中，我的一些軟件因?yàn)閺?fù)雜設(shè)計(jì)導(dǎo)致開發(fā)成本上升的時(shí)候，我重新思考這個(gè)問題，發(fā)現(xiàn)簡(jiǎn)單的設(shè)計(jì)是有道理的。
降低開發(fā)的成本
不論是模式，可重用組件，或是框架技術(shù)，目的都是為了降低開發(fā)的成本。但是他們的方式是先進(jìn)行大量的投入，然后再節(jié)省后續(xù)的開發(fā)成本。因此，架構(gòu)設(shè)計(jì)方面的很多思路都是圍繞著這種想法展開的，這可能也是導(dǎo)致開發(fā)人員普遍認(rèn)為架構(gòu)設(shè)計(jì)高不可攀的原因。
XP的方式恰恰相反，在處理第一個(gè)問題的時(shí)候，不必要也不可能就設(shè)計(jì)出具有彈性、近乎完美的架構(gòu)來。這項(xiàng)工作應(yīng)該是隨著開發(fā)的演進(jìn)，慢慢成熟起來的。我不敢說這種方式肯定正確，但是如果我們把生物的結(jié)構(gòu)視同為架構(gòu)，這種方式不是很類似于自然界中生物的進(jìn)化方式嗎？
在一開始就制作出完美的架構(gòu)的設(shè)想并沒有錯(cuò)，關(guān)鍵是很難做到這一點(diǎn)?？偸菚?huì)有很多的問題是你在做設(shè)計(jì)時(shí)沒有考慮到的。這樣，當(dāng)一開始花費(fèi)大量精力設(shè)計(jì)出的"完美無缺"的架構(gòu)必然會(huì)遇到意想不到的問題，這時(shí)候，復(fù)雜的架構(gòu)反而會(huì)影響到設(shè)計(jì)的改進(jìn)，導(dǎo)致開發(fā)成本的上升。這就好比如果方向錯(cuò)了，交通工具再快，反而導(dǎo)致錯(cuò)誤的快速擴(kuò)大。Martin Fowler在他的論文中說，"Working on the wrong solution early is even more wasteful than working on the right solution early"（提前做一件錯(cuò)事要比提前做一件對(duì)的事更浪費(fèi)時(shí)間），相信也是這個(gè)道理。
更有意思的是，通常我們更有可能做錯(cuò)。在我們進(jìn)行架構(gòu)設(shè)計(jì)的時(shí)候，我們不可能完全取得詳細(xì)的需求。事實(shí)上，就算你已經(jīng)取得了完整的需求，也有可能發(fā)生變化。這種情況下做出的架構(gòu)設(shè)計(jì)是不可能不出錯(cuò)的。這樣，浪費(fèi)大量的時(shí)間在初始階段設(shè)計(jì)不可能達(dá)到的"完美架構(gòu)"，倒不如把時(shí)間花在后續(xù)的改進(jìn)上。
提升溝通的效率
我們?cè)趫F(tuán)隊(duì)設(shè)計(jì)中已經(jīng)談過了團(tuán)隊(duì)設(shè)計(jì)的目標(biāo)之一就是為了降低溝通的成本，以期讓所有人都能夠理解架構(gòu)。但是如果架構(gòu)如果過于復(fù)雜，將會(huì)重新導(dǎo)致溝通成本的上升，而且，這個(gè)成本并不會(huì)隨著項(xiàng)目進(jìn)行而降低，反而會(huì)因?yàn)樯厦嫖覀兲岬降挠龅叫碌膯栴}導(dǎo)致溝通成本的持續(xù)上升。
簡(jiǎn)單的架構(gòu)設(shè)計(jì)可以加快開發(fā)團(tuán)隊(duì)理解架構(gòu)的速度。我們可以通過兩種方式來理解簡(jiǎn)單的含義。首先，簡(jiǎn)單意味著問題的解不會(huì)非常的復(fù)雜，架構(gòu)是解決需求的關(guān)鍵，無論需求再怎么復(fù)雜多變，總是可以找出簡(jiǎn)單穩(wěn)定的部分，我們可以把這個(gè)簡(jiǎn)單穩(wěn)定的部分做為基礎(chǔ)，再根據(jù)需要進(jìn)行改進(jìn)擴(kuò)展，以解決復(fù)雜的問題。在示例中，我們提到了measurement pattern，它就是按照這種想法來進(jìn)行設(shè)計(jì)的。
其次，簡(jiǎn)單性還體現(xiàn)在表示的簡(jiǎn)單上。一份5頁的文檔就能夠表達(dá)清楚的架構(gòu)設(shè)計(jì)為什么要花費(fèi)50頁呢？同樣的道理，能夠用一副簡(jiǎn)單的圖形就能夠表示的架構(gòu)設(shè)計(jì)也沒有必要使用文檔。畢竟，面對(duì)面的溝通才是率的溝通，文檔不論如何的復(fù)雜，都不能被完全理解，而且，復(fù)雜的文檔，維護(hù)起來也需要花費(fèi)大量的時(shí)間。只有在兩種情況下，我們提倡使用復(fù)雜的文檔：一是開發(fā)團(tuán)隊(duì)沒有辦法做到面對(duì)面溝通；二是開發(fā)成果要作為團(tuán)隊(duì)的知識(shí)積累起來，為下一次開發(fā)所用。
考慮未來
我們之所以考慮未來，主要的原因就是需求的不穩(wěn)定。因此，我們?nèi)绻紤]未來可能發(fā)生的需求變化，就會(huì)不知覺的在架構(gòu)設(shè)計(jì)中增加復(fù)雜的成分。這違背的簡(jiǎn)單的精神。但是，如果你不考慮可能出現(xiàn)的情況，那些和目前設(shè)計(jì)格格不入的改變，將會(huì)導(dǎo)致大量的返工。
還記得YAGNI嗎？原則上，我們?nèi)匀粓?jiān)持不要在現(xiàn)有的系統(tǒng)中為將來可能的情況進(jìn)行設(shè)計(jì)。但是，我們必須思考，必須要為將來可能出現(xiàn)的情況做一些準(zhǔn)備。其實(shí)，軟件中了不起的接口的思想，不就是源于此嗎？因此，思考未來，但等到需要時(shí)再實(shí)現(xiàn)。
變更案例有助于我們思考未來，變更案例就是你在將來可能要（或可能不要）滿足的，但現(xiàn)在不需要滿足的需求。當(dāng)我們?cè)谧黾軜?gòu)設(shè)計(jì)的時(shí)候，變更案例也將會(huì)成為設(shè)計(jì)的考慮因素之一，但它不可能成為進(jìn)行決策的考慮因素。很多的時(shí)候，我們沉迷于設(shè)計(jì)通用系統(tǒng)給我們帶來的挑戰(zhàn)之中，其實(shí)，我們所做的工作對(duì)用戶而言是毫無意義的。
架構(gòu)的穩(wěn)定
架構(gòu)簡(jiǎn)單化和架構(gòu)的穩(wěn)定性有什么關(guān)系嗎？我們說，架構(gòu)越簡(jiǎn)單，其穩(wěn)定性就越好。理由很簡(jiǎn)單，1個(gè)擁有4個(gè)方法和3個(gè)屬性的類，和1個(gè)擁有20個(gè)方法和30屬性的類相比，哪一個(gè)更穩(wěn)定？當(dāng)然是前者。而架構(gòu)最終都是要映射到代碼級(jí)別上的，因此架構(gòu)的簡(jiǎn)單將會(huì)帶來架構(gòu)的穩(wěn)定。盡可能的讓你的類小一些，盡可能的讓你的方法短一些，盡可能的讓類之間的關(guān)系少一些。這并不是我的忠告，很多的設(shè)計(jì)類的文章都是這么說的。在這個(gè)話題上，我們可以進(jìn)一步的閱讀同類的文章（關(guān)于 refactoring 的思考）。
辨正的簡(jiǎn)單
因此，對(duì)我們來說，簡(jiǎn)單的意義就是不要把未來的、或不需要實(shí)現(xiàn)的功能加入到目前的軟件中，相應(yīng)的架構(gòu)設(shè)計(jì)也不需要考慮這些額外的需求，只要?jiǎng)偤媚軌驖M足當(dāng)前的需求就好了。這就是簡(jiǎn)單的定義?？墒窃诂F(xiàn)實(shí)之中，總是有這樣或者那樣的原因，使得設(shè)計(jì)趨向復(fù)雜。一般來說，如果一個(gè)設(shè)計(jì)對(duì)團(tuán)隊(duì)而言是有價(jià)值的，那么，付出一定的成本來研究、驗(yàn)證、發(fā)展、文檔化這個(gè)設(shè)計(jì)是有意義的。反之，如果一個(gè)設(shè)計(jì)沒有很大的價(jià)值或是發(fā)展它的成本超過了其能夠提供的價(jià)值，那就不需要去考慮這個(gè)設(shè)計(jì)。
價(jià)值對(duì)不同的團(tuán)隊(duì)來說具有不同的含義。有時(shí)候可能是時(shí)間，有時(shí)候可能是用戶價(jià)值，有時(shí)候可能是為了團(tuán)隊(duì)的設(shè)計(jì)積累和代碼重用，有時(shí)候是為了獲得經(jīng)驗(yàn)，有時(shí)候是為了研究出可重用的框架（FrameWork）。這些也可以稱為目的，因此，你在設(shè)計(jì)架構(gòu)時(shí)，請(qǐng)注意先確定好你的目的，對(duì)實(shí)現(xiàn)目的有幫助的事情才考慮。
Scott W.Ambler在他的文章中提到一個(gè)他親身經(jīng)歷的故事，在軟件開發(fā)的架構(gòu)設(shè)計(jì)過程中，花了很多的時(shí)間來設(shè)計(jì)數(shù)據(jù)庫(kù)到業(yè)務(wù)邏輯的映射架構(gòu)，雖然這是一件任何開發(fā)人員都樂意專研的事情（因?yàn)樗芸幔?。但他不得不承認(rèn)，對(duì)用戶來說，這種設(shè)計(jì)先進(jìn)的架構(gòu)是沒有太大的意義的，因?yàn)橛脩舨⒉魂P(guān)心具體的技術(shù)。當(dāng)看到這個(gè)故事的時(shí)候，我的觸動(dòng)很大。一個(gè)開發(fā)人員總是熱衷于新奇的技術(shù)，但是如果這個(gè)新奇技術(shù)的成本由用戶來承擔(dān)，是不是合理呢？雖然新技術(shù)的采用能夠?yàn)橛脩魩硇б?，但是沒有人計(jì)算過效益背后的成本。就我開發(fā)過的項(xiàng)目而言，這個(gè)成本往往是大于效益的。這個(gè)問題可能并沒有確定的答案，只能是見仁見智了。
架構(gòu)應(yīng)該設(shè)計(jì)到什么程度？
軟件的架構(gòu)都是非常的復(fù)雜的，帶有大量的文檔和圖表。開發(fā)人員花在理解架構(gòu)本身上的時(shí)間甚至超出了實(shí)現(xiàn)架構(gòu)的時(shí)間。在前面的文章中，我們提到了一些反對(duì)象牙塔式架構(gòu)的一個(gè)原因，而其中的一個(gè)原因就是象牙塔式架構(gòu)的設(shè)計(jì)者往往在設(shè)計(jì)時(shí)參雜進(jìn)過多的自身經(jīng)驗(yàn)，而不是嚴(yán)格的按照需求來進(jìn)行設(shè)計(jì)。
在軟件開發(fā)領(lǐng)域，最為常見的設(shè)計(jì)就是"Code and Fix"方式的設(shè)計(jì)，設(shè)計(jì)隨著軟件開發(fā)過程而增長(zhǎng)。或者，我們可以認(rèn)為這種方式根本就不能算是設(shè)計(jì)，它抱著一種船到橋頭自然直的態(tài)度，可是在設(shè)計(jì)不斷改動(dòng)之后，代碼變得臃腫且難以理解，到處充滿著重復(fù)的代碼。這樣的情形下，架構(gòu)的設(shè)計(jì)也就無從談起，軟件就像是在風(fēng)雨中的破屋，瀕臨倒塌。
針對(duì)于這種情形，新的設(shè)計(jì)方式又出現(xiàn)了，Martin Fowler稱這種方式為"Planned Design"。和建筑的設(shè)計(jì)類似，它強(qiáng)調(diào)在編碼之前進(jìn)行嚴(yán)格的設(shè)計(jì)。這也就是我們?cè)趫F(tuán)隊(duì)設(shè)計(jì)中談到的架構(gòu)設(shè)計(jì)師的典型做法。設(shè)計(jì)師們通常不會(huì)去編程，理由是在土木工程中，你不可能看到一位設(shè)計(jì)師還要砌磚頭。
"Planned Design"較之"Code and Fix"進(jìn)步了許多，但是還是會(huì)存在很多問題。除了在團(tuán)隊(duì)設(shè)計(jì)中我們談的問題之外，需求變更將會(huì)導(dǎo)致更大的麻煩。因此，我們理所當(dāng)然的想到進(jìn)行"彈性設(shè)計(jì)"：彈性的設(shè)計(jì)能夠滿足需求的變更。而彈性的設(shè)計(jì)所付出的代價(jià)就是復(fù)雜的設(shè)計(jì)。
題外話：
這里我們談?wù)?Planned Design"引出的一些問題，并沒有任何排斥這種方式的意思。"Planned Design"還是有很多可取之處的，但也有很多需要改進(jìn)的地方。事實(shí)上，本文中我們討論的架構(gòu)設(shè)計(jì)方式，本質(zhì)上也是屬于"Planned Design"方式。和"Planned Design"相對(duì)應(yīng)的方式是XP所主張的"Evolutionary Design"方式，但是這種方式還有待于實(shí)踐的檢驗(yàn)，并不能簡(jiǎn)單的說他就一定要比"Planned Design"先進(jìn)或落后。但可以肯定的一點(diǎn)是："Evolutionary Design"方式中有很多的思想和技巧是值得"Planned Design"借鑒的。
解決方法：
XP中有兩個(gè)非常響亮的口號(hào)："Do The Simplest Thing that Could Possibly Work"和"You Aren't Going to Need It"（通常稱之為YAGNI）。他們的核心思想就是不要為了考慮將來，把目前并不需要的功能加到軟件中來。
粗看之下，會(huì)有很多開發(fā)人員認(rèn)為這是不切實(shí)際的口號(hào)。我能理解這種想法，其實(shí)，在我熱衷于模式、可重用組件技術(shù)的時(shí)候，我對(duì)XP提倡的簡(jiǎn)單的口號(hào)嗤之以鼻。但在實(shí)際中，我的一些軟件因?yàn)閺?fù)雜設(shè)計(jì)導(dǎo)致開發(fā)成本上升的時(shí)候，我重新思考這個(gè)問題，發(fā)現(xiàn)簡(jiǎn)單的設(shè)計(jì)是有道理的。
降低開發(fā)的成本
不論是模式，可重用組件，或是框架技術(shù)，目的都是為了降低開發(fā)的成本。但是他們的方式是先進(jìn)行大量的投入，然后再節(jié)省后續(xù)的開發(fā)成本。因此，架構(gòu)設(shè)計(jì)方面的很多思路都是圍繞著這種想法展開的，這可能也是導(dǎo)致開發(fā)人員普遍認(rèn)為架構(gòu)設(shè)計(jì)高不可攀的原因。
XP的方式恰恰相反，在處理第一個(gè)問題的時(shí)候，不必要也不可能就設(shè)計(jì)出具有彈性、近乎完美的架構(gòu)來。這項(xiàng)工作應(yīng)該是隨著開發(fā)的演進(jìn)，慢慢成熟起來的。我不敢說這種方式肯定正確，但是如果我們把生物的結(jié)構(gòu)視同為架構(gòu)，這種方式不是很類似于自然界中生物的進(jìn)化方式嗎？
在一開始就制作出完美的架構(gòu)的設(shè)想并沒有錯(cuò)，關(guān)鍵是很難做到這一點(diǎn)?？偸菚?huì)有很多的問題是你在做設(shè)計(jì)時(shí)沒有考慮到的。這樣，當(dāng)一開始花費(fèi)大量精力設(shè)計(jì)出的"完美無缺"的架構(gòu)必然會(huì)遇到意想不到的問題，這時(shí)候，復(fù)雜的架構(gòu)反而會(huì)影響到設(shè)計(jì)的改進(jìn)，導(dǎo)致開發(fā)成本的上升。這就好比如果方向錯(cuò)了，交通工具再快，反而導(dǎo)致錯(cuò)誤的快速擴(kuò)大。Martin Fowler在他的論文中說，"Working on the wrong solution early is even more wasteful than working on the right solution early"（提前做一件錯(cuò)事要比提前做一件對(duì)的事更浪費(fèi)時(shí)間），相信也是這個(gè)道理。
更有意思的是，通常我們更有可能做錯(cuò)。在我們進(jìn)行架構(gòu)設(shè)計(jì)的時(shí)候，我們不可能完全取得詳細(xì)的需求。事實(shí)上，就算你已經(jīng)取得了完整的需求，也有可能發(fā)生變化。這種情況下做出的架構(gòu)設(shè)計(jì)是不可能不出錯(cuò)的。這樣，浪費(fèi)大量的時(shí)間在初始階段設(shè)計(jì)不可能達(dá)到的"完美架構(gòu)"，倒不如把時(shí)間花在后續(xù)的改進(jìn)上。
提升溝通的效率
我們?cè)趫F(tuán)隊(duì)設(shè)計(jì)中已經(jīng)談過了團(tuán)隊(duì)設(shè)計(jì)的目標(biāo)之一就是為了降低溝通的成本，以期讓所有人都能夠理解架構(gòu)。但是如果架構(gòu)如果過于復(fù)雜，將會(huì)重新導(dǎo)致溝通成本的上升，而且，這個(gè)成本并不會(huì)隨著項(xiàng)目進(jìn)行而降低，反而會(huì)因?yàn)樯厦嫖覀兲岬降挠龅叫碌膯栴}導(dǎo)致溝通成本的持續(xù)上升。
簡(jiǎn)單的架構(gòu)設(shè)計(jì)可以加快開發(fā)團(tuán)隊(duì)理解架構(gòu)的速度。我們可以通過兩種方式來理解簡(jiǎn)單的含義。首先，簡(jiǎn)單意味著問題的解不會(huì)非常的復(fù)雜，架構(gòu)是解決需求的關(guān)鍵，無論需求再怎么復(fù)雜多變，總是可以找出簡(jiǎn)單穩(wěn)定的部分，我們可以把這個(gè)簡(jiǎn)單穩(wěn)定的部分做為基礎(chǔ)，再根據(jù)需要進(jìn)行改進(jìn)擴(kuò)展，以解決復(fù)雜的問題。在示例中，我們提到了measurement pattern，它就是按照這種想法來進(jìn)行設(shè)計(jì)的。
其次，簡(jiǎn)單性還體現(xiàn)在表示的簡(jiǎn)單上。一份5頁的文檔就能夠表達(dá)清楚的架構(gòu)設(shè)計(jì)為什么要花費(fèi)50頁呢？同樣的道理，能夠用一副簡(jiǎn)單的圖形就能夠表示的架構(gòu)設(shè)計(jì)也沒有必要使用文檔。畢竟，面對(duì)面的溝通才是率的溝通，文檔不論如何的復(fù)雜，都不能被完全理解，而且，復(fù)雜的文檔，維護(hù)起來也需要花費(fèi)大量的時(shí)間。只有在兩種情況下，我們提倡使用復(fù)雜的文檔：一是開發(fā)團(tuán)隊(duì)沒有辦法做到面對(duì)面溝通；二是開發(fā)成果要作為團(tuán)隊(duì)的知識(shí)積累起來，為下一次開發(fā)所用。
考慮未來
我們之所以考慮未來，主要的原因就是需求的不穩(wěn)定。因此，我們?nèi)绻紤]未來可能發(fā)生的需求變化，就會(huì)不知覺的在架構(gòu)設(shè)計(jì)中增加復(fù)雜的成分。這違背的簡(jiǎn)單的精神。但是，如果你不考慮可能出現(xiàn)的情況，那些和目前設(shè)計(jì)格格不入的改變，將會(huì)導(dǎo)致大量的返工。
還記得YAGNI嗎？原則上，我們?nèi)匀粓?jiān)持不要在現(xiàn)有的系統(tǒng)中為將來可能的情況進(jìn)行設(shè)計(jì)。但是，我們必須思考，必須要為將來可能出現(xiàn)的情況做一些準(zhǔn)備。其實(shí)，軟件中了不起的接口的思想，不就是源于此嗎？因此，思考未來，但等到需要時(shí)再實(shí)現(xiàn)。
變更案例有助于我們思考未來，變更案例就是你在將來可能要（或可能不要）滿足的，但現(xiàn)在不需要滿足的需求。當(dāng)我們?cè)谧黾軜?gòu)設(shè)計(jì)的時(shí)候，變更案例也將會(huì)成為設(shè)計(jì)的考慮因素之一，但它不可能成為進(jìn)行決策的考慮因素。很多的時(shí)候，我們沉迷于設(shè)計(jì)通用系統(tǒng)給我們帶來的挑戰(zhàn)之中，其實(shí)，我們所做的工作對(duì)用戶而言是毫無意義的。
架構(gòu)的穩(wěn)定
架構(gòu)簡(jiǎn)單化和架構(gòu)的穩(wěn)定性有什么關(guān)系嗎？我們說，架構(gòu)越簡(jiǎn)單，其穩(wěn)定性就越好。理由很簡(jiǎn)單，1個(gè)擁有4個(gè)方法和3個(gè)屬性的類，和1個(gè)擁有20個(gè)方法和30屬性的類相比，哪一個(gè)更穩(wěn)定？當(dāng)然是前者。而架構(gòu)最終都是要映射到代碼級(jí)別上的，因此架構(gòu)的簡(jiǎn)單將會(huì)帶來架構(gòu)的穩(wěn)定。盡可能的讓你的類小一些，盡可能的讓你的方法短一些，盡可能的讓類之間的關(guān)系少一些。這并不是我的忠告，很多的設(shè)計(jì)類的文章都是這么說的。在這個(gè)話題上，我們可以進(jìn)一步的閱讀同類的文章（關(guān)于 refactoring 的思考）。
辨正的簡(jiǎn)單
因此，對(duì)我們來說，簡(jiǎn)單的意義就是不要把未來的、或不需要實(shí)現(xiàn)的功能加入到目前的軟件中，相應(yīng)的架構(gòu)設(shè)計(jì)也不需要考慮這些額外的需求，只要?jiǎng)偤媚軌驖M足當(dāng)前的需求就好了。這就是簡(jiǎn)單的定義?？墒窃诂F(xiàn)實(shí)之中，總是有這樣或者那樣的原因，使得設(shè)計(jì)趨向復(fù)雜。一般來說，如果一個(gè)設(shè)計(jì)對(duì)團(tuán)隊(duì)而言是有價(jià)值的，那么，付出一定的成本來研究、驗(yàn)證、發(fā)展、文檔化這個(gè)設(shè)計(jì)是有意義的。反之，如果一個(gè)設(shè)計(jì)沒有很大的價(jià)值或是發(fā)展它的成本超過了其能夠提供的價(jià)值，那就不需要去考慮這個(gè)設(shè)計(jì)。
價(jià)值對(duì)不同的團(tuán)隊(duì)來說具有不同的含義。有時(shí)候可能是時(shí)間，有時(shí)候可能是用戶價(jià)值，有時(shí)候可能是為了團(tuán)隊(duì)的設(shè)計(jì)積累和代碼重用，有時(shí)候是為了獲得經(jīng)驗(yàn)，有時(shí)候是為了研究出可重用的框架（FrameWork）。這些也可以稱為目的，因此，你在設(shè)計(jì)架構(gòu)時(shí)，請(qǐng)注意先確定好你的目的，對(duì)實(shí)現(xiàn)目的有幫助的事情才考慮。
Scott W.Ambler在他的文章中提到一個(gè)他親身經(jīng)歷的故事，在軟件開發(fā)的架構(gòu)設(shè)計(jì)過程中，花了很多的時(shí)間來設(shè)計(jì)數(shù)據(jù)庫(kù)到業(yè)務(wù)邏輯的映射架構(gòu)，雖然這是一件任何開發(fā)人員都樂意專研的事情（因?yàn)樗芸幔?。但他不得不承認(rèn)，對(duì)用戶來說，這種設(shè)計(jì)先進(jìn)的架構(gòu)是沒有太大的意義的，因?yàn)橛脩舨⒉魂P(guān)心具體的技術(shù)。當(dāng)看到這個(gè)故事的時(shí)候，我的觸動(dòng)很大。一個(gè)開發(fā)人員總是熱衷于新奇的技術(shù)，但是如果這個(gè)新奇技術(shù)的成本由用戶來承擔(dān)，是不是合理呢？雖然新技術(shù)的采用能夠?yàn)橛脩魩硇б?，但是沒有人計(jì)算過效益背后的成本。就我開發(fā)過的項(xiàng)目而言，這個(gè)成本往往是大于效益的。這個(gè)問題可能并沒有確定的答案，只能是見仁見智了。