最近和大家一起討論了一些內(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)功能太多了，有時(shí)候是越想越多，如何選取合適的功能集合成為討論的焦點(diǎn);

    2)還有就是設(shè)計(jì)的靈活性和擴(kuò)展性的把握，感覺好的設(shè)計(jì)，往往需要更多實(shí)現(xiàn)的時(shí)間，然后項(xiàng)目時(shí)間似乎又不允許。

    在說明這兩個(gè)問題之前，我想有必要稍微說明一下軟件質(zhì)量的一些分類。

    最近看一本書(scrum and xp from the trenches)，對(duì)軟件的質(zhì)量，劃分為內(nèi)部質(zhì)量(internal quality)和外部質(zhì)量(external quality)，外部質(zhì)量指的是從客戶角度可以看到的質(zhì)量，比如軟件的功能，易用性、性能等等;內(nèi)部質(zhì)量則是是從程序員角度來看的質(zhì)量，比如代碼的健壯性、可擴(kuò)展性、可維護(hù)性等等。外部質(zhì)量好的軟件，內(nèi)部質(zhì)量不一定好;但是內(nèi)部質(zhì)量不好的軟件，外部質(zhì)量一般很難好。很難想像，一個(gè)設(shè)計(jì)很糟糕，代碼質(zhì)量很糟糕的系統(tǒng)，功能、性能和易用性可以很好。內(nèi)部質(zhì)量就好比是外部質(zhì)量的基石，代碼的可維護(hù)性和擴(kuò)展性，直接影響了系統(tǒng)的功能的改進(jìn)和提升。

    外部質(zhì)量和內(nèi)部質(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)目時(shí)間點(diǎn)的功能，這時(shí)大家都不免感到有些失落。

    那我們可以怎么處理呢，可以稍微分析一下我們整理出來的功能點(diǎn)，我們會(huì)發(fā)現(xiàn)，情況也許不是我們想像的那么糟糕。我自己覺得有四個(gè)原則可以幫助我們?nèi)ゾ駬瘢?/p>

    <!--[if !supportlists]-->1)<!--[endif]-->功能優(yōu)先級(jí)

    <!--[if !supportlists]-->2)<!--[endif]-->80/20法則

    <!--[if !supportlists]-->3)<!--[endif]-->完整性

    <!--[if !supportlists]-->4)<!--[endif]-->可持續(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í)現(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)是可以不斷去疊加來完善的，而不是說不斷的推翻后重新實(shí)現(xiàn)一把，這個(gè)是差別很大的。比如說內(nèi)容創(chuàng)建功能，現(xiàn)在對(duì)于異常的處理我們暫時(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ì)的的不可持續(xù)性了。功能點(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)用上面的一些原則，就能夠讓我們做的更好。

    在head first object-oriented design的書中，定義good design就是flexible design。而the art of agile software development一書中，定義good design為“a good software design minimizes the time required to create, modify and maintain the software while achieving acceptable runtime performance.”就是軟件的可維護(hù)性。所以agile design強(qiáng)調(diào)的功能，基本上都是從如何不斷改進(jìn)軟件的可維護(hù)性和可擴(kuò)展性而努力的，只有軟件具備了良好的可維護(hù)性和可擴(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í)間的沖突，這個(gè)可以回到前面開始談的內(nèi)部質(zhì)量和外部質(zhì)量的問題，前面對(duì)于功能(外部質(zhì)量)的問題，我們已經(jīng)談了取舍的方法，那么，內(nèi)部質(zhì)量(設(shè)計(jì))，是不是也可以取舍呢?在“scrum and xp from the trenches”書里面，作者自己是這么認(rèn)為的：

    internal quality, however, is not up for discussion. it is the team’s responsibility to maintain the system’s quality under all circumstances and this is simply not negotiable. ever.

    在這上面我是持一樣的觀點(diǎn)的。

    然而我們的問題依然存在。和項(xiàng)目時(shí)間的沖突如何平衡呢?我想可以考慮兩個(gè)原則：

    <!--[if !supportlists]-->1) <!--[endif]-->足夠好(first right)

    <!--[if !supportlists]-->2) <!--[endif]-->分階段實(shí)現(xiàn)/可持續(xù)性

    1)足夠好(first right & good enough)

    所謂first right & good enough是讓我們看看我們所作的設(shè)計(jì)是不是足夠清晰的架構(gòu)我們的系統(tǒng)，而不是太過的復(fù)雜導(dǎo)致項(xiàng)目時(shí)間不足，往往好的設(shè)計(jì)并不是要花更多的時(shí)間實(shí)現(xiàn)的，通常只有over design才讓我們感到力不從心。所以我們發(fā)現(xiàn)設(shè)計(jì)導(dǎo)致實(shí)現(xiàn)的時(shí)間過長(zhǎng)的時(shí)候，我們需要看看，是不是我們想的太復(fù)雜了?

    另外一方面，我們不提倡over design，避免needless complexity，但是還是要good enough & first right，就是在看的到的需求范圍內(nèi)，我們的設(shè)計(jì)要好，好的設(shè)計(jì)和不好的設(shè)計(jì)，差別往往是在維護(hù)代碼和增加功能的時(shí)候才能夠看到，稍微花一些時(shí)間完成一些精妙的設(shè)計(jì)，不僅是技術(shù)，更是藝術(shù)美感的體現(xiàn)，這個(gè)只有在未來才能夠體會(huì)到。

    要注意的是refactoring和first right并沒有沖突，只有每次都是right的比wrong的更多，逐步的將wrong的地方進(jìn)行refactor，系統(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è)話單有好幾種格式，那么它的設(shè)計(jì)可以有幾個(gè)階段：

    第一個(gè)階段是能夠在類這個(gè)層級(jí)易于維護(hù)，先通過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è)階段是把類的可維護(hù)性提升到配置的可維護(hù)性，比如說通過一種xml的方式來配置話單格式，使得系統(tǒng)的可維護(hù)性達(dá)到運(yùn)行時(shí)而不是編譯時(shí)。這個(gè)時(shí)候，還是在原來的基礎(chǔ)上，生成一個(gè)新的子類，這個(gè)子類在formatcdr的時(shí)候是從xml配置文件里面讀取配置后生成格式化數(shù)據(jù)的罷了，系統(tǒng)還是支持很多種默認(rèn)的cdr格式并且對(duì)于一些無法通過配置的cdr格式，還是可以通過子類繼承的方式來實(shí)現(xiàn)。

    第三個(gè)階段是做一個(gè)很好的gui來配置和管理話單xml配置文件了。

    所以往往好的設(shè)計(jì)是可以逐步疊加并且完善的，象spring的核心ioc就是為了設(shè)計(jì)模式而生的，很好的運(yùn)用這些技術(shù)和理念，是可以讓我們的設(shè)計(jì)具有更好的生命力和持續(xù)性，同時(shí)也平衡項(xiàng)目中的一些時(shí)間點(diǎn)。

    結(jié)語：無論如何，軟件的需求分析和設(shè)計(jì)，都是一種藝術(shù)，是要在我們不斷的開發(fā)過程中去積累和提高的，要做到最好，所有的付出，都是值得的。