Shopify如何使用Strangler Fig模式重構遺留程式碼中上帝式大物件？- Adrianna Chang

banq發表於2020-03-13
模式物件

大物件散佈了程式碼的壞味道：隨著職責和依賴的不斷增長，它們變得越來越繁重，要定義它們究竟要負責什麼變得更加困難。大物件更難重用，測試也較慢。更糟糕的是，它們花費了開發人員更多的時間和精力來理解，從而增加了引入錯誤的機會。未經檢查的大物件冒著將程式碼庫其餘部分變成泥潭的風險，但是請不要擔心！有一些策略可以減小大物件的大小和責任。
Shopify是一個多合一的商務平臺，為全球超過一百萬的商人提供支援。 Shopify的Ruby on Rails程式碼庫中最關鍵的區域之一。Shop是一門繁重的大物件類，有超過3000行程式碼，其職責不勝列舉。當Shopify是一傢俱有較小程式碼庫的較小公司時，Shop的目的職責很明確：它代表了託管在我們平臺上的線上商店。今天，Shopify變得更加複雜，Shop模式的商業意圖變得更加模糊。可以將其描述為“ 上帝物件”：一個知道很多並且做得太多的類。
我的團隊Kernel Architecture Patterns負責在Shopify程式碼庫中實施乾淨，高效，可擴充套件的體系結構。在過去的幾年中，我們付出了巨大的努力來組建Shopify的整體程式碼庫（請參閱解構整體），目的是在Shopify平臺的不同域之間建立明確定義的邊界。
在元件級別建立邊界不僅重要，而且在元件內的物件之間建立邊界也很重要。明確定義物件建模的業務子域非常重要。這樣可以確保班級具有明確的界限和明確定義的職責集。
Shop的定義不清楚，語義邊界也很弱。不幸的是，這使其成為增加新功能和複雜性的簡單目標。作為倡導乾淨，建模良好的程式碼的倡導者，很明顯，團隊需要開始研究Shop模型，並將其某些業務流程移至更合適的物件或元件中。

使用ABC程式碼量度確定程式碼質量
找到起點的一種方法是使用程式碼度量工具。只要選擇適合您的程式碼庫，選擇哪一個都不重要。我們的團隊選擇使用Flog，該程式碼根據程式碼每個區域中的分配，分支和呼叫的數量使用分數，以瞭解程式碼質量遭受最大影響的地方。Shop類中發現了一個特別混亂的部分，其中包含與Shopify商店相關的眾多“全域性屬性”。

用Strangler Fig模式進行重構
將Shop中的設定屬性提取到更合適的元件中可帶來許多好處，尤其是得到更好的凝聚力，以及無關程式碼與Shop模型的分離。重構工作是一項艱鉅的任務，其中大多數設定在整個程式碼庫的各個位置都被引用，通常是團隊不熟悉的元件。我們知道我們可能會對這些設定應移至何處做出錯誤的假設。我們想要確保提取過程的佈局合理，並且在我們對建模決策改變主意或犯錯誤的情況下，採取的任何步驟都易於逆轉。確保Shopify不會停機的情況也是一個關鍵要求，並且一勞永逸地從舊系統遷移到全新系統似乎是災難的根源。

什麼是Strangler Fig模式
解決方案？馬丁·福勒（Martin Fowler）的扼殺無花果圖案。不要讓這個名字嚇到你！Strangler Fig模式為重構程式碼提供了一個增量，可靠的過程。它描述了一種方法，透過該方法，新系統可以在舊系統之上緩慢增長，直到舊系統被“勒死”並可以輕鬆刪除為止。這種方法的優點在於，更改可以隨時進行增量監控，並且發生意外中斷的可能性非常低。在我們確信新系統可以按預期執行之前，舊系統將保持不變，然後刪除所有舊程式碼就很簡單了。

步驟：
步驟1：為需要提取的設定屬性定義一個介面，該介面將依賴於現有的Shop物件，並將繼續訪問shop資料庫表中的資料。

步驟2：將客戶呼叫從舊系統改為呼叫新系統。

步驟3：如果需要編寫新系統的新資料來源

步驟4：在新模型中實現新的寫入新資料來源程式碼

步驟5：用舊資料回填新資料來源

步驟6：更改新定義的介面中的方法以從新資料來源中讀取資料

步驟7：停止寫入舊原始碼並刪除舊版程式碼

具體步驟點選標題見原文

 

相關文章