抽象分歧
2014 年 1 月 7 日
「抽象分歧」是一種技術[1],用於以漸進的方式對軟體系統進行大規模變更,讓您可以在變更仍在進行時定期發布系統。
我們從一個情況開始,軟體系統的各個部分依賴於我們想要替換的模組、函式庫或架構
我們建立一個抽象層,用於擷取客戶端程式碼的一個區段與目前供應商之間的互動。我們變更客戶端程式碼的那個區段,以完全透過這個抽象層呼叫供應商。
我們逐漸將所有客戶端程式碼移轉到使用抽象層,直到與供應商的所有互動都由抽象層完成。在這樣做的過程中,我們會利用這個抽象層來提升供應商的單元測試涵蓋率。
我們使用相同的抽象層[2]建立一個新的供應商,用於實作客戶端程式碼一部分所需的特性。準備好後,我們會切換客戶端程式碼的那個區段,以使用新的供應商。
我們逐漸替換有缺陷的供應商,直到所有客戶端程式碼都使用新的供應商。一旦不再需要有缺陷的供應商,我們就可以將其刪除。我們也可以選擇在不再需要抽象層時將其刪除,以進行移轉。
我以上的說明描述了一個常見案例,但可能會發生許多變化。有時候您無法只針對部分客戶端替換供應商,您必須一次全部完成。有時候您可以將供應商的特性分解成不同的子元件,並一次執行一個子元件的整個程序。
儘管有這些變化,但有一個共同的主題。使用抽象層以允許多個實作在軟體系統中共存。使用一個抽象和多個實作的概念來執行從一個實作到另一個實作的遷移。確保系統在任何時候都能正確建置和執行,這樣您就可以在進行替換時繼續使用持續交付。尋找盡可能多的方法來逐步進行變更。
進一步閱讀
Jez Humble 描述他的團隊如何使用「抽象分支」來替換 Thoughtworks 的持續交付工具「Go」的物件關聯對應架構 (ibatis 到 Hibernate) 和 Web UI 架構 (velocity/JsTemplate 到 Ruby on Rails)。
Paul Hammant 提供更多詳細資訊,特別是使用「抽象分支」作為版本控制分支的替代方案。
Steve Smith 描述了一個變體,其中包括驗證兩個實作是否對要求傳回相同的結果。