在開發工作中，我們常常要將整體的開發內容分解成一些較小的部分，分而治之。 原因不限於以下幾種：
- 分解和抽象使得開發內容更容易被理解。
- 可以將分解后的開發內容分配給多人開發。
- 分解后的開發時間更容易估算，進度更易於衡量，有利於做計劃。
古人說“橫看成嶺側成峰”，意指從不同的角度觀察事物時會得到不同的抽象。開發工作與之類似，當開發者從不同的角度進行分解工作時，會對開發內容產生不同的理解，因此分解后得出的產物可能也並不相同。從哪些角度對開發內容的分解才是最優的？這往往沒有固定的答案，要由分解的目的決定。下面會介紹9種常見分解角度。
本文鏈接：https://www.cnblogs.com/hhelibeb/p/13070646.html
轉載請註明
形式與結構
形式與結構，指的是開發內容中全部的開發對象，以及它們之間的關係。比如，一個客戶信用檢查程序可能包含表、視圖、鎖對象、接口、類等一些開發對象，它們之間會存在一定的連接關係。
從這個角度分解的優點在於它十分具體，有一些屬性可以通過求和直接得到，例如，表和字段的數量意味着要增加多少種存儲信息。
對形式的分析也可以提示開發者將連接關係較多的東西歸為一組，如果把它們分解到不同的地方，可能會導致複雜度增加，需要很多額外的工作來傳遞信息，對開發內容的分析和理解將變得困難。
功能
形式代表了靜態存在的對象，而功能是指它們能做什麼。功能是開發工作的價值體現。
一般來說，程序的命名即可提現它的功能。比如“供應商信用檢查程序”顯然指出了程序的功能是檢查供應商的信用。如果將這個程序從功能角度分解，可以分解為設定信用額度的功能、計算佔用額度的功能、集成到付款/採購流程的功能、從外部系統查詢供應商信用的功能等。
按功能分解開發對象是最直觀的分解方式之一，它有助於開發者從系統整體層面思考問題。比如，如果要考慮程序的性能問題，從功能角度的分解可以讓人分析各個子功能的性能如何、它們集成到一起時有可能發生什麼問題。又比如，如果要增加一個“黑名單/白名單”子功能的話，我們可以從功能角度審視這一新功能對其它各個子功能產生何種影響。
設計的自由度
如果能把緊密耦合的對象歸為一個模塊，並使之與外界盡可能的隔離，就能在模塊內部得到更大的自由度。
這裏以abap-data-validator為例，該項目的每個檢查規則都位於單獨的類中，這些類實現了同一個接口ZIF_ADV_CHECK，如下圖。這使得每個類的開發者不需要與其它類的開發者共享任何信息，可以在自己負責的類中任意發揮，實現功能。而ZIF_ADV_CHECK約束了這些類，使它們遵循相同的檢查接口約定。
另一種思路是把這些檢查功能都放置在同一個類中，用不同的類方法實現它們，如下圖。顯而易見，這樣做的好處是降低了總體複雜度（方法數不變，類減少為1個），缺點是不同的方法會共享類的信息，有可能出現一些跨方法的東西，這會降低設計的自由度。對檢查接口的約束也成為了一種隱式的規則，這會增大開發者的心智負擔，容易產生誤解。
這兩種做法沒有絕對的優劣，abap-data-validator選擇了前者，是因為開發者在經過權衡后認為，為了讓社區的同行方便地增加自己的新的檢查規則，付出增加一定的複雜度的代價是可以接受的。雖然到目前為止尚還沒有人給這個項目貢獻新規則。
程序的進化
程序的功能通常有不斷增加的趨勢 ，我們把功能增加的過程稱為進化。從進化的角度進行分解時，開發者需要考慮如何讓新舊功能方便地結合。以創建採購訂單的程序為例，如果考慮到程序未來會有對訂單進行其它檢查的需求，那麼就要分解出單獨的檢查模塊，並提供接口。這樣的話，如果要增加供應商信用檢查功能，那麼只要通過這個接口來實現就好。從進化角度的分解可以讓程序在在進化中保持架構的穩定。
系統間的集成
系統間集成的工作常常會出現很多誤解，因為系統間通常只靠接口交流，其它信息完全是隱藏的。未知帶來了思維盲區和錯誤假設。我之前也寫過博客感慨這類工作的不易（《 關於
接口開發和聯調的一些感想 》）。 從集成角度分解開發內容時，一個重要目標是盡可能
避免誤解。這要求，
- 接口要易於測試。這樣可以增加接口的可信度，測試也有利於人們理解接口的功能。
- 接口的表面複雜度要低。這意味着要對接口內部進行分解，將複雜度轉移到下層，或者將某些副作用轉移到接口之外的其它地方。
技術更新
我們時常需要使用新技術替換舊技術，這會為我們帶來功能、性能或者KPI上的收益。從技術更新的角度考慮開發內容的分解時，就要把特定技術相關的部分分離，從而使得在不影響其它部分的情況下將技術變化，或者讓新舊技術可以同時運行，逐步替換舊技術。
銷售
有時，出於營銷與銷售的目的，程序的某些特性需要可以組合、開關、調節、修飾。這時，開發者需要從銷售的角度思考開發內容的分解，做出可定製的程序，滿足銷售的目的。
投資
對於老闆們來說，開發是一項針對未來的投資。他們預先支付薪水，接着期望開發者們交付的東西能幫助公司節約開支、獲取收入。他們的心中可能存在一個簡單公式，用來衡量程序開發工作的意義：
利潤 = 收入 – 費用
付給開發人員的錢可以被看做費用，那麼，收入在哪裡？分解開發內容時，要注意分解后的模塊可以在一定的投資下產生價值，並且需要論證如果有後續投資的話可以產生更多價值。否則老闆們可能會認為把開發人員裁掉才是更經濟的選擇。
組織架構
康威定律指出：
設計系統的架構受制於產生這些設計的組織的溝通結構。
就像程序模塊間存在信息傳遞的問題一樣，不同的團隊之間的溝通也會存在問題。程序的分解應該和組織形成匹配的關係，這樣可以避免一些額外的工作和糟糕的結果。
以上文提到過的為例，開源社區的開發成員之間只有鬆散的連接關係，因此，如果該項目的目標是讓社區成員參与開發，那麼就要盡可能地減少檢查類之間的共享信息，選取第一種分解方式。如下圖，
反之，如果這完全是個內部項目，由單人開發，且完成後接口幾乎不會發生變化，那麼第二種分解方式可能更為合適。如下圖，
總結
本文介紹了開發內容分解的9個角度，這些角度在具體的實踐中可能有重合或者衝突。從不同的角度考慮分解工作可以讓我們產生不同的理解，更全面地審視自己的工作。但要注意的是分解並非越多越好，比如在設計自由度中我們提到分解導致的複雜度增加也會成為代價。要從整體考慮和觀察開發內容，選取合適的角度。本文也沒有涵蓋所有的分解角度。
本文的主要思想來自於《 系統架構》，結合了個人的一些開發實踐，有興趣了解更多的話可以看這本書。 本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※帶您來了解什麼是 USB CONNECTOR ?
※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面
※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!
※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化
※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益
※教你寫出一流的銷售文案?
