開發內容分解的9個角度

在開發工做中，咱們經常要將總體的開發內容分解成一些較小的部分，分而治之。 緣由不限於如下幾種：

• 分解和抽象使得開發內容更容易被理解。
• 能夠將分解後的開發內容分配給多人開發。
• 分解後的開發時間更容易估算，進度更易於衡量，有利於作計劃。

古人說「橫當作嶺側成峯」，意指從不一樣的角度觀察事物時會獲得不一樣的抽象。開發工做與之相似，當開發者從不一樣的角度進行分解工做時，會對開發內容產生不一樣的理解，所以分解後得出的產物可能也並不相同。從哪些角度對開發內容的分解纔是最優的？這每每沒有固定的答案，要由分解的目的決定。下面會介紹9種常見分解角度。

 

本文連接：http://www.javashuo.com/article/p-grucqqre-b.html

轉載請註明

形式與結構

形式與結構，指的是開發內容中所有的開發對象，以及它們之間的關係。好比，一個客戶信用檢查程序可能包含表、視圖、鎖對象、接口、類等一些開發對象，它們之間會存在必定的鏈接關係。

從這個角度分解的優勢在於它十分具體，有一些屬性能夠經過求和直接獲得，好比，表和字段的數量意味着要增長多少種存儲信息。

對形式的分析能夠提示開發者將鏈接關係較多的東西歸爲一組，若是把它們分解到不一樣的地方，可能會致使複雜度增長，須要不少額外的工做來傳遞信息，對開發內容的分析和理解將變得困難。

功能

形式表明了靜態存在的對象，而功能是指它們能作什麼。功能是開發工做的價值體現。

通常來講，程序的命名便可提現它的功能。好比「供應商信用檢查程序」顯然指出了程序的功能是檢查供應商的信用。若是將這個程序從功能角度分解，能夠分解爲設定信用額度的功能、計算佔用額度的功能、集成到付款/採購流程的功能、從外部系統查詢供應商信用的功能等。

按功能分解開發對象是最直觀的分解方式之一，它有助於開發者從系統總體層面思考問題。好比，若是要考慮程序的性能問題，從功能角度的分解可讓人分析各個子功能的性能如何、它們集成到一塊兒時有可能發生什麼問題。又好比，若是要增長一個「黑名單/白名單」子功能的話，咱們能夠從功能角度審視這一新功能對其它各個子功能產生何種影響。

設計的自由度

若是能把緊密耦合的對象歸爲一個模塊，並使之與外界儘量的隔離，就能在模塊內部獲得更大的自由度。

這裏以abap-data-validator爲例，該項目的每一個檢查規則都位於單獨的類中，這些類實現了同一個接口ZIF_ADV_CHECK，以下圖。這使得每一個類的開發者不須要與其它類的開發者共享任何信息，能夠在本身負責的類中任意發揮，實現功能。而ZIF_ADV_CHECK約束了這些類，使它們遵循相同的檢查接口約定。

 

另外一種思路是把這些檢查功能都放置在同一個類中，用不一樣的類方法實現它們，以下圖。顯而易見，這樣作的好處是下降了整體複雜度（方法數不變，類減小爲1個），缺點是不一樣的方法會共享類的信息，有可能出現一些跨方法的東西，這會下降設計的自由度。對檢查接口的約束也成爲了一種隱式的規則，這會增大開發者的心智負擔，容易產生誤解。

 

 

這兩種作法沒有絕對的優劣，abap-data-validator選擇了前者，是由於開發者在通過權衡後認爲，爲了讓社區的同行方便地增長本身的新的檢查規則，付出增長必定的複雜度的代價是能夠接受的。雖然到目前爲止尚尚未人給這個項目貢獻新規則。

程序的進化

程序的功能一般有不斷增長的趨勢 ，咱們把功能增長的過程稱爲進化。從進化的角度進行分解時，開發者須要考慮如何讓新舊功能方便地結合。以建立採購訂單的程序爲例，若是考慮到程序將來會有對訂單進行其它檢查的需求，那麼就要分解出單獨的檢查模塊，並提供接口。這樣的話，若是要增長供應商信用檢查功能，那麼只要經過這個接口來實現就好。從進化角度的分解可讓程序在在進化中保持架構的穩定。

系統間的集成

系統間集成的工做經常會出現不少誤解，由於系統間一般只靠接口交流，其它信息徹底是隱藏的。未知帶來了思惟盲區和錯誤假設。我以前也寫過博客感慨這類工做的不易（《 關於接口開發和聯調的一些感想 》）。

從集成角度分解開發內容時，一個重要目標是儘量 避免誤解。這要求，

• 接口要易於測試。這樣能夠增長接口的可信度，測試也有利於人們理解接口的功能。
• 接口的表面複雜度要低。這意味着要對接口內部進行分解，將複雜度轉移到下層，或者將某些反作用轉移到接口以外的其它地方。

技術更新

咱們時常須要使用新技術替換舊技術，這會爲咱們帶來功能、性能或者KPI上的收益。從技術更新的角度考慮開發內容的分解時，就要把特定技術相關的部分分離，從而使得在不影響其它部分的狀況下將技術變化，或者讓新舊技術能夠同時運行，逐步替換舊技術。

銷售

有時，出於營銷與銷售的目的，程序的某些特性須要能夠組合、開關、調節、修飾。這時，開發者須要從銷售的角度思考開發內容的分解，作出可定製的程序，知足銷售的目的。

投資

對於老闆們來講，開發是一項針對將來的投資。他們預先支付薪水，接着指望開發者們交付的東西能幫助公司節約開支、獲取收入。他們的心中可能存在一個簡單公式，用來衡量程序開發工做的意義：

利潤 = 收入 – 費用

付給開發人員的錢能夠被看作費用，那麼，收入在哪裏？分解開發內容時，要注意分解後的模塊能夠在必定的投資下產生價值，而且須要能夠論證若是有後續投資的話能夠產生更多價值。不然老闆們可能會認爲把開發人員裁掉纔是更經濟的選擇。

組織架構

康威定律指出：

設計系統的架構受制於產生這些設計的組織的溝通結構。

就像程序模塊間存在信息傳遞的問題同樣，不一樣的團隊之間的溝通也會存在問題。程序的分解應該和組織造成匹配的關係，這樣能夠避免一些額外的工做和糟糕的結果。

以上文提到過的爲例，開源社區的開發成員之間只有鬆散的鏈接關係，所以，若是該項目的目標是讓社區成員參與開發，那麼就要儘量地減小檢查類之間的共享信息，選取第一種分解方式。以下圖，

反之，若是這徹底是個內部項目，由單人開發，且完成後接口幾乎不會發生變化，那麼第二種分解方式可能更爲合適。以下圖，

總結

本文介紹了開發內容分解的9個角度，這些角度在具體的實踐中可能有重合或者衝突。從不一樣的角度考慮分解工做可讓咱們產生不一樣的理解，更全面地審視本身的工做。但要注意的是分解並不是越多越好，好比在設計自由度中咱們提到分解致使的複雜度增長也會成爲代價。要從總體考慮和觀察開發內容，選取合適的角度。本文也沒有涵蓋全部的分解角度。

 

本文的主要思想來自於《 系統架構》，結合了我的的一些開發實踐，有興趣瞭解更多的話能夠看這本書。