組件和依賴管理
《持續交付 發佈可靠軟件的系統方法》讀書筆記
當我們說起組件時，是指應用程序中的一個規模相當大的代碼結構，它具有一套定義良好的 API，而且可以被另一種實現方式代替。 對於一個基於組件的軟件系統來說，通常其代碼庫被分成多個相互分離的部分，每個部分通過個數有限的定義良好的接口提供一些服務行爲，與其他組件進行有限的交互。
基於組件的設計通常被認爲是一種良好的架構，具有松耦合性，是一種鼓勵重用的設計。事實也確實如此。但它還有另外一個重要的好處：對於大型軟件開發團隊的協作來說，它是最有效的方法之一。
保持應用程序可發佈
爲了在變更的同時還能保持應用程序的可發佈，有如下四種應對策略：
-
將新功能隱蔽起來，直到它完成爲止。
-
將所有的變更都變成一系列的增量式小修改，而且每次小的修改都是可發佈的。
-
使用通過抽象來模擬分支（branch by abstraction）的方式對代碼庫進行大範圍的變更。
-
使用組件，根據不同部分修改的頻率對應用程序進行解耦。
依賴
在構建或運行軟件時，軟件的一部分要依賴於另一部分，就產生了依賴關係。
組件（component）和庫（library）之間的差異，庫是指團隊除了選擇權以外，沒有控制權的那些軟件包，它們通常很少更新。相反，組件是指應用程序所依賴的部分軟件塊，但它通常是由你自己的團隊或你公司中的其他團隊開發的。組件通常更新頻繁。這種區別非常重要，因爲當設計構建流程時，處理組件要比處理庫所需考慮的事情多一些。
構建時依賴與運行時依賴之間的差異，構建時依賴會出現在應用程序編譯和鏈接時（如果需要編譯和鏈接的話）；而運行時依賴會出現在應用程序運行並完成它的某些操作時。
組件
幾乎所有的現代軟件系統都是由組件組成的。
爲什麼說組件開發方式讓軟件開發流程更高效：
-
它將問題分成更小且更達意的代碼塊。
-
組件常常表示出系統不同部分代碼的變化率不同，並且有不同的生命週期。
-
它鼓勵我們使用清晰的職責描述來設計並維護軟件，反過來也限制了因修改產生的影響，並使理解和修改代碼庫變得更容易。
-
它給我們提供了額外的自由度來優化構建和部署過程。
並不建議讓每個團隊各自負責一個獨立的組件。因爲在大多數情況下，需求不會按組件的邊界來分。根據我們的經驗，那些有能力開發端到端功能的跨功能團隊更加高效。儘管一個團隊負責一個組件看上去好像更高效，但事實並非如此。
常常很難只修改一個單獨的組件就能實現和測試某個需求，因爲通常實現一個功能需要修改多個組件。如果你按組件劃分團隊的話，就需要兩個或以上的團隊合作才能完成一個功能，自然會增加更多且非必要的溝通成本。而且，在圍繞組件組成的團隊中，大家傾向於形成 “筒倉”（silo），並進行局部優化，從而失去從全局觀點出發來評判項目的最佳利益的能力。
最好劃分多個團隊，以便每個團隊都可以拿到一系列的用戶故事（這些故事可能屬於同一主題）。爲了完成這些需求，每個團隊都可以修改任何組件的代碼。一個團隊爲了實現某個業務特性可以自由修改任何組件是一種更高效的工作方式。依據功能領域而不是組件來組建團隊確保了每個人都有權力修改代碼庫的任何部分，同時在團隊之間定期交換人員，確保團隊之間有良好的溝通。
小結
討論了既能讓應用程序一直處於可發佈狀態，又能儘可能讓團隊高效開發的技術。原則就是確保團隊儘快得到代碼修改後所產生的影響。達到這一目標的一種策略就是確保將每次修改都分解成小且增量式的步驟，並小步提交。還有一種策略是將應用程序分解成多個組件。
將應用程序分解成一組松耦合且具有良好封閉性的協作組件不只是一種好的設計。而且，對於一個大系統的開發來說，還可以提高工作效率，得到更快的反饋。直到應用程序變得足夠大時，才需要對組件進行分別構建。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/VzZT6mPt3DWVX7wq8YVsZg