超碰人人人人人,色婷婷综合久久久久中文一区二区,国产-第1页-浮力影院,欧美老妇另类久久久久久

    最近和大家一起討論了一些內(nèi)容管理方面的功能和設(shè)計，有些思考，和大家分享一下。

    在討論內(nèi)容管理的功能需求時，我們常常會考慮某個功能各種各樣的情況，功能性、易用性、復(fù)雜的處理場景、異常的處理場景，這些無疑都是非常非常有價值的，一個系統(tǒng)做到最好的境界，從客戶角度來看，也就是這些功能了。

    同時，我們也討論了很多軟件設(shè)計方面的一些內(nèi)容，考慮了很多靈活性、擴(kuò)展性方面的內(nèi)容，同時設(shè)計和功能也是緊密相連的，設(shè)計常常對功能的具體展現(xiàn)會有一定的影響。

    那我們實際中遇到的困難是什么呢?針對上面我們討論的兩個方面，主要是兩個問題：

    1)功能太多了，有時候是越想越多，如何選取合適的功能集合成為討論的焦點;

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

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

    最近看一本書(scrum and xp from the trenches)，對軟件的質(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ì)量一般很難好。很難想像，一個設(shè)計很糟糕，代碼質(zhì)量很糟糕的系統(tǒng)，功能、性能和易用性可以很好。內(nèi)部質(zhì)量就好比是外部質(zhì)量的基石，代碼的可維護(hù)性和擴(kuò)展性，直接影響了系統(tǒng)的功能的改進(jìn)和提升。

    外部質(zhì)量和內(nèi)部質(zhì)量比較容易對于到功能和設(shè)計兩個問題上。

    那么回過頭來看我們遇到的兩個問題，首先是功能的取舍問題。

    我們agile的團(tuán)隊討論，大家對于某個user story，討論起來越談就越起勁，想出了好多好多的功能點，隨之也帶來了很多麻煩，比如說要實現(xiàn)的范圍好像太大了，似乎一下子工作量變得很大，隨著而來也有很多壓力，然后接著我們有時候也會不由自主的按照項目時間點，尋找一些“捷徑”，然后可能就逐步丟掉了或者少做了一些好的功能點，甚至?xí)D(zhuǎn)向?qū)崿F(xiàn)一些大家雖然覺得不怎么好但是滿足項目時間點的功能，這時大家都不免感到有些失落。

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

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

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

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

    <!--[if !supportlists]-->4)<!--[endif]-->可持續(xù)性

    1)優(yōu)先級

    首先是我們可以按照優(yōu)先級來選擇功能點，這個是顯而易見的。重要的功能先做，次要的功能可以先放一放。特別是最基本的功能，比如客戶一定要的功能，沒有這個功能客戶就玩不轉(zhuǎn)了;比如內(nèi)容管理，如果內(nèi)容創(chuàng)建、修改和刪除，這些功能如果都沒有，那么系統(tǒng)都無法正常運轉(zhuǎn)了，肯定是不行的了。

    2)80/20法則

    80/20法則，就是先選擇哪些客戶日常使用最需要用到的功能，比如說內(nèi)容處理的基本流程，有一些內(nèi)容同步的異常情況，實現(xiàn)起來是很復(fù)雜的，但是實際中遇到的可能性相對較少。又比如內(nèi)容創(chuàng)建流程的易用性，這個用戶使用頻率是非常高的，那么怎么優(yōu)化內(nèi)容創(chuàng)建的用戶體驗，這個功能點優(yōu)先級也就是很高的，然而它的代價可能不會特別高。

    3)完整性

    要特別注意是功能點的完整性，比如說內(nèi)容異常流程的處理，假設(shè)因為項目時間，先不實現(xiàn)了，那么也不是說完全不處理異常了，還是要做到有一定完整性，即使是簡單的實現(xiàn)也是需要的(比如說記錄日志以供人工查詢)，但是這個簡單實現(xiàn)是代價最小的，而且是以后可以很快去替代的。

    4)可持續(xù)性

    功能點的實現(xiàn)選擇，要考慮的還有可持續(xù)性的問題，就是功能點是可以不斷去疊加來完善的，而不是說不斷的推翻后重新實現(xiàn)一把，這個是差別很大的。比如說內(nèi)容創(chuàng)建功能，現(xiàn)在對于異常的處理我們暫時不實現(xiàn)，這個是沒有問題的;但是如果下次要實現(xiàn)異常處理的時候，就要把現(xiàn)在內(nèi)容創(chuàng)建的流程的功能描述推翻重來，這個可持續(xù)性就有問題了，因為這個意味著以前的功能全部都會被推翻，很可能是以前的實現(xiàn)都白費了，這就是功能點設(shè)計的的不可持續(xù)性了。功能點設(shè)計一定要有持續(xù)性，如果是這樣子，系統(tǒng)的功能就能夠越做越強。

    所以我們可以把每一個的user story的各個功能點想的更加完善，這個是很好的，剩下的只是如何取舍的了，所謂取舍，只是階段性的舍棄和選擇罷了。所以在討論過程中，不要因為功能的增強，范圍的擴(kuò)大而讓我們感到害怕和困惑，把他們記錄下來，就是很好的逐步改進(jìn)系統(tǒng)的武器，我們只要運用上面的一些原則，就能夠讓我們做的更好。

    在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強調(diào)的功能，基本上都是從如何不斷改進(jìn)軟件的可維護(hù)性和可擴(kuò)展性而努力的，只有軟件具備了良好的可維護(hù)性和可擴(kuò)展性，那么軟件能夠很好的不斷疊加功能，軟件才具有旺盛的生命力。

    我們實際中面向的問題呢?其實還是很簡單，就是好的設(shè)計和項目時間的沖突，好的設(shè)計是需要時間考慮的，也是需要時間來實現(xiàn)的(雖然不是絕對，有時候好的設(shè)計會節(jié)省更多的工作量)。

    對于第一個問題，于項目時間的沖突，這個可以回到前面開始談的內(nèi)部質(zhì)量和外部質(zhì)量的問題，前面對于功能(外部質(zhì)量)的問題，我們已經(jīng)談了取舍的方法，那么，內(nèi)部質(zhì)量(設(shè)計)，是不是也可以取舍呢?在“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.

    在這上面我是持一樣的觀點的。

    然而我們的問題依然存在。和項目時間的沖突如何平衡呢?我想可以考慮兩個原則：

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

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

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

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

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

    要注意的是refactoring和first right并沒有沖突，只有每次都是right的比wrong的更多，逐步的將wrong的地方進(jìn)行refactor，系統(tǒng)才能夠越做越好。否則系統(tǒng)的質(zhì)量就始終處于初級階段了。

    2)分階段實現(xiàn)/可持續(xù)性

    好的設(shè)計往往是flexible的，是可以分階段實現(xiàn)的，很多設(shè)計的基本原則，比如面向接口編程，就是支撐“分階段實現(xiàn)”的一個很好的原則。當(dāng)我們定義的接口層次很清晰的時候，接口的具體實現(xiàn)，是可以根據(jù)項目的時間點，進(jìn)行控制的。項目時間比較緊的時候，可以做一些快速的實現(xiàn)，然后在下一階段再refactoring，如果對象之間是接口依賴而不是類依賴的話，下一階段的refactoring也對系統(tǒng)已有功能影響也就非常的小，這個也是ioc核心價值所在了。

    舉個例子，比如說話單文件格式的靈活設(shè)計，假設(shè)話單有好幾種格式，那么它的設(shè)計可以有幾個階段：

    第一個階段是能夠在類這個層級易于維護(hù)，先通過template的設(shè)計模式定義一個話單父類后，不同的話單格式的子類實現(xiàn)父類的模板方法，如formatcdr(格式話話單記錄)即可，這種情況下，外部函數(shù)寫話單的時候，只需要實例化相應(yīng)對象后，調(diào)用父類的接口就可以寫出相應(yīng)的話單。而有新話單格式的時候，只要生成一個新的子類并實現(xiàn)相應(yīng)方法就可以了，可以看到這種設(shè)計是一個good enough的設(shè)計。

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

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

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

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