細(xì)說可持續(xù)的需求分析和軟件設(shè)計(jì)

1、細(xì)說可持續(xù)的需求分析和設(shè)計(jì)摘要：本文將詳細(xì)為大家講解可持續(xù)的需求分析和整性等各方面的內(nèi)容。設(shè)計(jì)，包括優(yōu)先級(jí)、80/20法則、完最近和大家一起了一些內(nèi)容管理方面的功能和設(shè)計(jì)，有些思考，和大家一下。在內(nèi)容管理的功能需求時(shí)，常常會(huì)考慮某個(gè)功能各種各樣的情況，功能性、易用性、復(fù)雜的處理場(chǎng)景、異常的處理場(chǎng)景，這些無疑都是非常非常有價(jià)值的，一個(gè)系統(tǒng)做到最好的境界，從客戶角度來看，也就是這些功能了。同時(shí)，也了很多設(shè)計(jì)方面的一些內(nèi)容，考慮了很多靈活性、擴(kuò)展性方面的內(nèi)容，同時(shí)設(shè)計(jì)和功能也是緊密相連的，設(shè)計(jì)常常對(duì)功能的具體展現(xiàn)會(huì)有一定的影響。那實(shí)際中遇到的是什么呢？針對(duì)上面的兩個(gè)方面，主要是兩個(gè)問題：1）功能太多

2、了，有時(shí)候是越想越多，如何選取合適的功能集為的焦點(diǎn)；2）還有就是設(shè)計(jì)的靈活性和擴(kuò)展性的把握，感覺好的設(shè)計(jì)，往往需要然后項(xiàng)目時(shí)間似乎又不允許。實(shí)現(xiàn)的時(shí)間，在說明這兩個(gè)問題之前，有必要稍微說明一下質(zhì)量的一些分類。最近看一本書（Scrum and XP from the Trenches），對(duì)的質(zhì)量，劃分為質(zhì)量（ ernal quality）和外部質(zhì)量（external quality），外部質(zhì)量指的是從客戶角度可以看到的質(zhì)量，比如的功能，易用性、性能等等；質(zhì)量則是是從程序員角度來看的質(zhì)量，比如代碼的健壯性、可擴(kuò)展性、可性等等。外部質(zhì)量好的，質(zhì)量不一定好；但是質(zhì)量不好的，外部質(zhì)量一般很難好。很難想像

3、，一個(gè)設(shè)計(jì)很糟糕，代碼質(zhì)量很糟糕的系統(tǒng)，功能、性能和易用性可以很好。質(zhì)量就好比是外部質(zhì)量的基石，代碼的可性和擴(kuò)展性，直接影響了系統(tǒng)的功能的改進(jìn)和。外部質(zhì)量和質(zhì)量比較容易對(duì)于到功能和設(shè)計(jì)兩個(gè)問題上。那么回過頭來看遇到的兩個(gè)問題，首先是功能的取舍問題。Agile 的團(tuán)隊(duì)，大家對(duì)于某個(gè) User Story，起來越談就越起勁，想出了好多好多的功能點(diǎn)，隨之也帶來了很多麻煩，比如說要實(shí)現(xiàn)的范圍好像太大了，似乎一下子工作量變得很大，隨著而來也有很多壓力，然后接著有時(shí)候也會(huì)不由的按照項(xiàng)目時(shí)間點(diǎn)，尋找一些“捷徑”，然后可能就逐步丟掉了或者少做了一些好的功能點(diǎn)，甚至?xí)D(zhuǎn)向?qū)崿F(xiàn)一些大家雖然覺得不怎么好但是滿足項(xiàng)目

4、時(shí)間點(diǎn)的功能，這時(shí)大家都不免感到有些失落。那可以怎么處理呢，可以稍微分析一下整理出來的功能點(diǎn)，會(huì)發(fā)現(xiàn)，情況也許不是想像的那么糟糕。覺得有四個(gè)原則可以幫助去抉擇：功能優(yōu)先級(jí)80/20法則完整性可持續(xù)性1）優(yōu)先級(jí)首先是可以按照優(yōu)先級(jí)來選擇功能點(diǎn)，這個(gè)是顯而易見的。重要的功能先做，次要的功能可以先放一放。特別是最基本的功能，比如客戶一定要的功能，沒有這個(gè)功能客戶就玩不轉(zhuǎn)了；比如內(nèi)容管理，如果內(nèi)容創(chuàng)建、修改和刪除，這些功能如果都沒有，那么系統(tǒng)都無法正常運(yùn)轉(zhuǎn)了，肯定是的了。2）80/20法則80/20法則，就是先選擇哪些客戶日常使用最需要用到的功能，比如說內(nèi)容處理的基本流程，有一些內(nèi)容同步的異常情況，實(shí)

5、現(xiàn)起來是很復(fù)雜的，但是實(shí)際中遇到的可能性相對(duì)較少。又比如內(nèi)容創(chuàng)建流程的易用性，這個(gè)用戶使用頻率是非常高的，那么怎么優(yōu)化內(nèi)容創(chuàng)建的用戶體驗(yàn)，這個(gè)功能點(diǎn)優(yōu)先級(jí)也就是很高的，然而它的代價(jià)可能不會(huì)特別高。3）完整性要特別注意是功能點(diǎn)的完整性，比如說內(nèi)容異常流程的處理，假設(shè)因?yàn)轫?xiàng)目時(shí)間，先不實(shí)現(xiàn)了，那么也不是說完全不處理異常了，還是要做到有一定完整性，即使是簡(jiǎn)單的實(shí)現(xiàn)也是需要的（比如說 日志以供人工查詢），但是這個(gè)簡(jiǎn)單實(shí)現(xiàn)是代價(jià)最小的，而且是以后可以很快去替代的。4）可持續(xù)性功能點(diǎn)的實(shí)現(xiàn)選擇，要考慮的還有可持續(xù)性，就是功能點(diǎn)是可以不斷去疊加來完善的，而不是說不斷的在對(duì)于異常的處理后重新實(shí)現(xiàn)一把，這個(gè)是差

6、別很大的。比如說內(nèi)容創(chuàng)建功能，現(xiàn)暫時(shí)不實(shí)現(xiàn)，這個(gè)是沒有問題的；但是如果下次要實(shí)現(xiàn)異常處理的時(shí)候，就要把現(xiàn)在內(nèi)容創(chuàng)建的流程的功能描述重來，這個(gè)可持續(xù)性就有問題了，因?yàn)檫@個(gè)意味著以前的功能全部都會(huì)被，很可能是以前的實(shí)現(xiàn)都白費(fèi)了，這就是功能點(diǎn)設(shè)計(jì)的的性了。功能點(diǎn)設(shè)計(jì)一定要有持續(xù)性，如果是這樣子，系統(tǒng)的功能就能夠越做越強(qiáng)。所以可以把每一個(gè)的 User Story 的各個(gè)功能點(diǎn)想的更加完善，這個(gè)是很好的，剩下的只是如何取舍的了，所謂取舍，只是階段性的舍棄和選擇罷了。所以在過程中，不要因?yàn)楣δ艿脑鰪?qiáng)，范圍的擴(kuò)大而讓感到害怕和困惑，把他們下來，就是很好的逐做的更好。步改進(jìn)系統(tǒng)的，只要運(yùn)用上面的一些原則，就能

7、夠讓下來再談?wù)勗O(shè)計(jì)在 HeadObject-Oriented Design 的書中，定義 Good Design 就是 Flexible Design。而 The Art of Agile Software Development 一書中，定義 Good Design 為“A good softwaredesign minimizes the time required to create，hieving acceptable runtime performance.”就是modify and maain the software while ac的可性。所以 Agile Design 強(qiáng)調(diào)的

8、功能，基本上都是從如何不斷改進(jìn)的可性和可擴(kuò)展性而努力的，只有具備了良好的可性和可擴(kuò)展性，那么能夠很好的不斷疊加功能，才具有旺盛的生命力。實(shí)際中面向呢？其實(shí)還是很簡(jiǎn)單，就是好的設(shè)計(jì)和項(xiàng)目時(shí)間的，好的設(shè)計(jì)是需要時(shí)間考慮的，也是需要時(shí)間來實(shí)現(xiàn)的（雖然不是絕對(duì)，有時(shí)候好的設(shè)計(jì)會(huì)節(jié)省的工作量）。對(duì)于第一個(gè)問題，于項(xiàng)目時(shí)間的，前面對(duì)于功能（外部質(zhì)量），這個(gè)可以回到前面開始談的質(zhì)量和外部質(zhì)量，已經(jīng)談了取舍的方法，那么，質(zhì)量（設(shè)計(jì)），是不是也可以取舍呢？在“Scrum and XP from the Trenches”書里面，作者自己是這么認(rèn)為的：ernal quality， however， is not

9、up for discus. It is the teams responsibility tomaain the systems quality under all circumstanver.and this is simply not negotiable. E在這上面我是持一樣的觀點(diǎn)的。然而依然存在。和項(xiàng)目時(shí)間的如何平衡呢？可以考慮兩個(gè)原則：足夠好（Right）分階段實(shí)現(xiàn)/可持續(xù)性1）足夠好（Right & Good Enough）所謂Right & Good Enough 是讓看看所作的設(shè)計(jì)是不是足夠清晰的架構(gòu)的系統(tǒng)，而不是太過的復(fù)雜導(dǎo)致項(xiàng)目時(shí)間，往往好的設(shè)計(jì)并不是要花的時(shí)間實(shí)現(xiàn)的，

10、通常只有 Over Design 才讓長(zhǎng)的時(shí)候，需要看看，是不是感到力不從心。所以想的太復(fù)雜了？發(fā)現(xiàn)設(shè)計(jì)導(dǎo)致實(shí)現(xiàn)的時(shí)間過另外一方面，不提倡 Over Design，避免 Needless Complexity，但是還是要 Good Enough &Right，就是在看的到的需求范圍內(nèi)，的設(shè)計(jì)要好，好的設(shè)計(jì)和不好的設(shè)計(jì)，差別往往是在代碼和增加功能的時(shí)候才能夠看到，稍微花一些時(shí)間完成一些精妙的設(shè)計(jì)，不僅是技術(shù)，更是藝術(shù)美感的體現(xiàn)，這個(gè)只有在未來才能夠體會(huì)到。要注意的是 Refactoring 和Right 并沒有，只有每次都是 Right 的比 Wrong 的，逐步的將 Wrong 的地方進(jìn)行 R

11、efactor，系統(tǒng)才能夠越做越好。否則系統(tǒng)的質(zhì)量就始終處于初級(jí)階段了。2）分階段實(shí)現(xiàn)/可持續(xù)性好的設(shè)計(jì)往往是 Flexible 的，是可以分階段實(shí)現(xiàn)的，很多設(shè)計(jì)的基本原則，比如面向接口編程，就是支撐“分階段實(shí)現(xiàn)”的一個(gè)很好的原則。當(dāng)定義的接口層次很清晰的時(shí)候，接口的具體實(shí)現(xiàn)，是可以根據(jù)項(xiàng)目的時(shí)間點(diǎn)，進(jìn)行控制的。項(xiàng)目時(shí)間比較緊的時(shí)候，可以做一些快速的實(shí)現(xiàn)，然后在下一階段再 Refactoring，如果對(duì)象之間是接口依賴而不是類依賴的話，下一階段的 Refactoring 也對(duì)系統(tǒng)已有功能影響也就非常的小，這個(gè)也是 IOC所在了。價(jià)值舉個(gè)例子，比如說話單文件格式的靈活設(shè)計(jì)，假設(shè)話單有好幾種格式，

12、那么它的設(shè)計(jì)可以有幾個(gè)階段：第一個(gè)階段是能夠在類這個(gè)層級(jí)易于，先通過 Template 的設(shè)計(jì)模式定義一個(gè)話單父類后，不同的話單格式的子類實(shí)現(xiàn)父類的模板方法，如 formatCDR（格式話話單）即可，這種情況下，外部函數(shù)寫話單的時(shí)候，只需要實(shí)例化相應(yīng)對(duì)象后，調(diào)用父類的接口就可以寫出相應(yīng)的話單。而有新話單格式的時(shí)候，只要生成一個(gè)新的子類并實(shí)現(xiàn)相應(yīng)方法就可以了，可以看到這種設(shè)計(jì)是一個(gè) Good Enough 的設(shè)計(jì)。第二個(gè)階段是把類的可配置話單格式，使得系統(tǒng)的可性到配置的可性，比如說通過一種 XML 的方式來性達(dá)到運(yùn)行時(shí)而不是編譯時(shí)。這個(gè)時(shí)候，還是在原來的基礎(chǔ)上，生成一個(gè)新的子類，這個(gè)子類在 formatCDR 的時(shí)候是從XML 配置文件里面配置后生成格式化數(shù)據(jù)的罷了，系統(tǒng)還是支持很多種默認(rèn)的 CDR 格式并且對(duì)于一些無法通過配置的 CDR 格式，還是可以通過子類繼承的方式來實(shí)