!supportLists]-->2） <!--[endif]-->分階段實現(xiàn)/可持續(xù)性
1）足夠好（First Right & Good Enough）
所謂First Right & Good Enough是讓我們看看我們所作的設(shè)計是不是足夠清晰的架構(gòu)我們的系統(tǒng)，而不是太過的復(fù)雜導致項目時間不足，往往好的設(shè)計并不是要花更多的時間實現(xiàn)的，通常只有Over Design才讓我們感到力不從心。所以我們發(fā)現(xiàn)設(shè)計導致實現(xiàn)的時間過長的時候，我們需要看看，是不是我們想的太復(fù)雜了？
另外一方面，我們不提倡Over Design，避免Needless Complexity，但是還是要Good Enough & First Right，就是在看的到的需求范圍內(nèi)，我們的設(shè)計要好，好的設(shè)計和不好的設(shè)計，差別往往是在維護代碼和增加功能的時候才能夠看到，稍微花一些時間完成一些精妙的設(shè)計，不僅是技術(shù)，更是藝術(shù)美感的體現(xiàn)，這個只有在未來才能夠體會到。
要注意的是Refactoring和First Right并沒有沖突，只有每次都是Right的比Wrong的更多，逐步的將Wrong的地方進行Refactor，系統(tǒng)才能夠越做越好。否則系統(tǒng)的質(zhì)量就始終處于初級階段了。
2）分階段實現(xiàn)/可持續(xù)性
好的設(shè)計往往是Flexible的，是可以分階段實現(xiàn)的，很多設(shè)計的基本原則，比如面向接口編程，就是支撐“分階段實現(xiàn)”的一個很好的原則。當我們定義的接口層次很清晰的時候，接口的具體實現(xiàn)，是可以根據(jù)項目的時間點，進行控制的。項目時間比較緊的時候，可以做一些快速的實現(xiàn)，然后在下一階段再Refactoring，如果對象之間是接口依賴而不是類依賴的話，下一階段的Refactoring也對系統(tǒng)已有功能影響也就非常的小，這個也是IOC核心價值所在了。
舉個例子，比如說話單文件格式的靈活設(shè)計，假設(shè)話單有好幾種格式，那么它的設(shè)計可以有幾個階段：
第一個階段是能夠在類這個層級易于維護，先通過Template的設(shè)計模式定義一個話單父類后，不同的話單格式的子類實現(xiàn)父類的模板方法，如formatCDR（格式話話單記錄）即可，這種情況下，外部函數(shù)寫話單的時候，只需要實例化相應(yīng)對象后，調(diào)用父類的接口就可以寫出相應(yīng)的話單。而有新話單格式的時候，只要生成一個新的子類并實現(xiàn)相應(yīng)方法就可以了，可以看到這種設(shè)計是一個Good Enough的設(shè)計。
第二個階段是把類的可維護性提升到配置的可維護性，比如說通過一種XML的方式來配置話單格式，使得系統(tǒng)的可維護性達到運行時而不是編譯時。這個時候，還是在原來的基礎(chǔ)上，生成一個新的子類，這個子類在formatCDR的時候是從XML配置文件里面讀取配置后生成格式化數(shù)據(jù)的罷了，系統(tǒng)還是支持很多種默認的CDR格式并且對于一些無法通過配置的CDR格式，還是可以通過子類繼承的方式來實現(xiàn)。
第三個階段是做一個很好的GUI來配置和管理話單XML配置文件了。
所以往往好的設(shè)計是可以逐步疊加并且完善的，象Spring的核心IOC就是為了設(shè)計模式而生的，很好的運用這些技術(shù)和理念，是可以讓我們的設(shè)計具有更好的生命力和持續(xù)性，同時也平衡項目中的一些時間點。
結(jié)語：無論如何，軟件的需求分析和設(shè)計，都是一種藝術(shù)，是要在我們不斷的開發(fā)過程中去積累和提高的，要做到最好，所有的付出，都是值得的。
項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~
http://opto-elec.com.cn/pmqhd/index.html
