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