這個(gè)話題來(lái)源于下午和同事們的討論，背景是這樣的：他們?cè)谝粋�(gè)小項(xiàng)目上工作，周期是4周，

如何把握系統(tǒng)設(shè)計(jì)的尺度

。第一周是第0個(gè)迭代，主要的工作為寫Story，做Spike等。而此后便開(kāi)始開(kāi)發(fā)，前幾天開(kāi)發(fā)的速度比較慢。因?yàn)樗麄兘?jīng)常在寫了一些代碼后又覺(jué)得，恩，結(jié)構(gòu)設(shè)計(jì)的不夠漂亮，中間應(yīng)該加一層之類的。所以大部分時(shí)間都在推翻設(shè)計(jì)，修改以及添加測(cè)試，重構(gòu)代碼，分解依賴，運(yùn)行Build腳本，提交代碼。

    問(wèn)題就出現(xiàn)了，敏捷開(kāi)發(fā)強(qiáng)調(diào)的是簡(jiǎn)單設(shè)計(jì)，Pair拿到一個(gè)Story的時(shí)候，分析業(yè)務(wù)需求，簡(jiǎn)單的討論設(shè)計(jì)（大概15-20分鐘），然后進(jìn)行開(kāi)發(fā)。在開(kāi)發(fā)過(guò)程中發(fā)現(xiàn)有重復(fù)代碼，進(jìn)行重構(gòu)，一切重復(fù)代碼都得重構(gòu)，包括測(cè)試。最終的結(jié)果就是，完成Story的時(shí)候，沒(méi)有重復(fù)代碼，這就是優(yōu)良的設(shè)計(jì)。但是優(yōu)秀的設(shè)計(jì)又要求容易擴(kuò)展，需求變化的時(shí)候盡量少的修改。當(dāng)代碼能夠很好完成它的功能，它就是有價(jià)值的，客戶并不關(guān)心你的代碼是否是低耦合，高內(nèi)聚，也不關(guān)心它是否是多層架構(gòu)的�；�了很多時(shí)間做了高擴(kuò)展的架構(gòu)，到項(xiàng)目結(jié)束也沒(méi)有要擴(kuò)展的需求，這是否值得呢？

    適當(dāng)?shù)脑O(shè)計(jì)是必要的，過(guò)多的設(shè)計(jì)是浪費(fèi)，關(guān)鍵是要把握設(shè)計(jì)的度。怎樣才是必要的呢？當(dāng)你知道某地方以后會(huì)變化，該地方就得對(duì)擴(kuò)展開(kāi)放。舉個(gè)例子，如果要你實(shí)現(xiàn)解析文件，然后把信息存入數(shù)據(jù)庫(kù)這樣一個(gè)功能，當(dāng)前只要求解析Xml，你可能會(huì)毫不猶豫的用XmlDocument。但是，后面的需求是必須支持更多的文件類型，比如Excel，Csv等，你就得考慮需要引入Strategy模式。我覺(jué)得這就是適當(dāng)?shù)脑O(shè)計(jì)，為以后的擴(kuò)展提供支持。如果你不考慮也可以，只是后面的開(kāi)發(fā)過(guò)程中會(huì)大量的重構(gòu)，修改測(cè)試，花更多時(shí)間，別人會(huì)說(shuō)你設(shè)計(jì)不好。那什么是過(guò)多的設(shè)計(jì)呢？很明顯客戶只需要支持Sql Server，那我在DAO中就使用SqlConnection等，而不必要引入Provider或者Sql Dialect以支持多數(shù)據(jù)庫(kù)的變化。這樣的設(shè)計(jì)就是浪費(fèi)。

    良好設(shè)計(jì)的不二法則，面向接口編程。接口減少了類和類之間的依賴，提高了可測(cè)試性，很方便的引入DI框架。但是如果你看到我們項(xiàng)目的代碼會(huì)發(fā)現(xiàn)，類之間全都是與接口交互，幾乎所有類都會(huì)抽出接口，盡管它只可能有一種實(shí)現(xiàn)。這樣做的目的是為了更好的使用Mock工具進(jìn)行單元測(cè)試，當(dāng)前還做不到Mock具體類而只能Mock接口。大量的接口伴隨著唯一的實(shí)現(xiàn)，為了測(cè)試而設(shè)計(jì)，也是不小的浪費(fèi)。我想肯定有更好的辦法，比如將某些耦合緊密的類看作一個(gè)組合，對(duì)它進(jìn)行單元測(cè)試。針對(duì)這些問(wèn)題，我還需要更多的學(xué)習(xí)。

    希望大家都來(lái)討論，你們?cè)陂_(kāi)發(fā)過(guò)程中是如何設(shè)計(jì)的，如何把握設(shè)計(jì)的度呢？

    評(píng)論

    #1樓caidehui      | 2008-06-10 23:41

    這個(gè)不是設(shè)計(jì)的尺度的問(wèn)題，而是設(shè)計(jì)能力的問(wèn)題，

管理資料

《如何把握系統(tǒng)設(shè)計(jì)的尺度》(http://www.ishadingyu.com)。

    不管是敏捷也好，非常正規(guī)的設(shè)計(jì)也好都是一樣的，要求設(shè)計(jì)本身是比較準(zhǔn)確的。

    敏捷的設(shè)計(jì)，是文檔少，直奔主題，講究快而準(zhǔn)，那么就要求我們的設(shè)計(jì)人員水平要比較高、團(tuán)隊(duì)成員的能力要相當(dāng)、大家心態(tài)都比較開(kāi)放。

    設(shè)計(jì)的最重要的原則還是隔離變化、要分清楚變化，面向接口編程可以換成一句話，叫面向使用編程，沒(méi)有使用就沒(méi)有接口了，而使用環(huán)境有可能變，所以接口要多多考慮使用的變化，從而在設(shè)計(jì)中將使用的變化能夠容納進(jìn)來(lái)。

    看看你介紹的問(wèn)題，還有一個(gè)致命的問(wèn)題，就是敏捷設(shè)計(jì)也需要架構(gòu)和框架，沒(méi)有這兩個(gè)東西，就沒(méi)有敏捷。將系統(tǒng)構(gòu)架在一個(gè)穩(wěn)定的基礎(chǔ)上是非常關(guān)鍵的。盡管這個(gè)基礎(chǔ)在項(xiàng)目開(kāi)發(fā)過(guò)程中還會(huì)發(fā)生變化，但這個(gè)變化應(yīng)該是可控的、頻率很小的。

    有了架構(gòu)與框架，后面的問(wèn)題自然就迎刃而解了。

    敏捷開(kāi)發(fā)如何設(shè)計(jì)架構(gòu)與開(kāi)發(fā)框架，當(dāng)然要在最開(kāi)始的迭代里面考慮，要使用1－2天的時(shí)間來(lái)分析所有的use story，如果沒(méi)有所有的use story 也要將涉及到的業(yè)務(wù)討論清楚，分析將來(lái)的擴(kuò)展情況，分析這樣的架構(gòu)在各種情況下的變化與應(yīng)對(duì)，再花上2－3天時(shí)間，實(shí)現(xiàn)這個(gè)框架，并能夠多方驗(yàn)證與證實(shí)。

    后面的迭代只要做好每次迭代要求的Use story 能夠在框架下按時(shí)、按量完成，那么基本上就成功了

    紫色陰影      | 2008-06-11 02:08

    @caidehui

    我覺(jué)得還是設(shè)計(jì)尺度的問(wèn)題，如何把握擴(kuò)展性，不管從是整體架構(gòu)來(lái)說(shuō)還是設(shè)計(jì)。

    文檔少不是設(shè)計(jì)的特點(diǎn)，而是開(kāi)發(fā)流程中的特點(diǎn)。你感覺(jué)沒(méi)有文檔，但是需要什么東西都可以找得到，所以說(shuō)敏捷開(kāi)發(fā)并不是不要文檔，而只是保證最少最需要的文檔，不用文檔來(lái)驅(qū)動(dòng)

    任何開(kāi)發(fā)方法都需要架構(gòu)和框架的，這些是開(kāi)發(fā)的基礎(chǔ)。敏捷開(kāi)發(fā)只是快速開(kāi)發(fā)出原型系統(tǒng)，無(wú)需太多考慮。

    變化是不可避免的，架構(gòu)也是隨之精化，當(dāng)項(xiàng)目結(jié)束的時(shí)候，從整體上來(lái)看，也許和最初的時(shí)候很相似，但細(xì)看往往大不一樣。

    來(lái)自：如何把握設(shè)計(jì)的尺度