狠狠色丁香婷婷综合尤物/久久精品综合一区二区三区/中国有色金属学报/国产日韩欧美在线观看 - 国产一区二区三区四区五区tv

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

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

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

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

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

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

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

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

    外部質量和內部質量比較容易對于到功能和設計兩個問題上。

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

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

    那我們可以怎么處理呢，可以稍微分析一下我們整理出來的功能點，我們會發現，情況也許不是我們想像的那么糟糕。我自己覺得有四個原則可以幫助我們去抉擇：

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

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

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

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

    1)優先級

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

    2)80/20法則

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

    3)完整性

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

    4)可持續性

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

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

    在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.”就是軟件的可維護性。所以agile design強調的功能，基本上都是從如何不斷改進軟件的可維護性和可擴展性而努力的，只有軟件具備了良好的可維護性和可擴展性，那么軟件能夠很好的不斷疊加功能，軟件才具有旺盛的生命力。

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

    對于第一個問題，于項目時間的沖突，這個可以回到前面開始談的內部質量和外部質量的問題，前面對于功能(外部質量)的問題，我們已經談了取舍的方法，那么，內部質量(設計)，是不是也可以取舍呢?在“scrum and xp from the trenches”書里面，作者自己是這么認為的：

    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]-->分階段實現/可持續性

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

    所謂first right & good enough是讓我們看看我們所作的設計是不是足夠清晰的架構我們的系統，而不是太過的復雜導致項目時間不足，往往好的設計并不是要花更多的時間實現的，通常只有over design才讓我們感到力不從心。所以我們發現設計導致實現的時間過長的時候，我們需要看看，是不是我們想的太復雜了?

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

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

    2)分階段實現/可持續性

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

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

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

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

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

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

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