[[404268]]

本文的讀者

• 你為代碼總是被同事們寫亂了而苦惱，但是又無法 Review 每一行代碼

• 你要開發一個 SaaS，實現各種復雜功能的組合，但是又不能像互聯網公司一樣堆很多人來開發微服務

• 你模仿過主流的微服務，DDD 等做法，但并沒有達到理想的效果，不介意嘗試一些非主流的新辦法

本文的目標是以盡可能濃縮的篇幅提供可模仿的步驟來達成“如何不 Review 每一行代碼，同時保持代碼不被寫亂”的目標?？偣踩?/p>

• 第一步：不要拆分代碼倉庫，不要拆微服務。Monorepo is all you need，Feature Toggle is all you need。

• 第二步：管控集成類需求的代碼審查：主板加插件。

• 第三步：管控規范型需求的代碼審查：獨家收口。

第一步：不要拆分代碼倉庫，不要拆微服務

拆分微服務以及代碼倉庫的缺點

• 利用組織邊界來強化代碼的分工邊界會導致將來調整阻力很大。我們對于代碼應該如何組織的認識是隨著新需求不斷調整的。不要輕易動用“組織架構”這樣的核武器來達成小目標。

• 拆分了代碼倉庫之后不利于在編譯期做集成，做集成后的整體驗證。即便運行時集成有萬般好處，也沒有必要喪失掉編譯期集成的選項。

• 跨代碼倉庫的代碼閱讀，開發時的輔助和檢查都會變困難。

• 微服務控制變更風險的灰度邊界是固化的，也就是微服務的大小。切得越細，每次變更的東西就越少，風險就越小。這不夠靈活。

• 微服務的彈性邊界是固化的，如果某種視頻編輯需要特別多的內存，我們希望獨立伸縮，就得把這部分代碼切割出來變成一個獨立的微服務。

拆分微服務和代碼倉庫相比單體架構，最重要的目標是減少分支沖突，控制發布變更的風險。但是拆分微服務和代碼倉庫并不是最佳的解決方案。Monorepo + Feature Toggle 是更好的解決方案。

• Monorepo：所有的代碼都在一個倉庫里。這樣就不存在不同模塊的倉庫有不同的版本問題。大家都是統一的一個版本。升級線上系統的過程拆分成：部署+發布，兩個步驟。部署的時候，整個 Monorepo 的代碼都部署到目標機器上了，但并不代表發布了。

• Feature Toggle：特性開關來精確控制哪些邏輯分支被發布出去。這樣部署就和發布解耦了。要灰度多少比例，可以精確控制。要一個特性開關的兩個版本的邏輯分支共存，也可以實現。

使用 Monorepo + Feature Toggle 可以提供所有拆分微服務達成的目標，同時克服以上微服務拆分帶來的缺點

• 通過目錄結構來控制代碼所有權。你可以要求這個目錄下的代碼必須經過你的 Code Review。調整目錄結構比調整代碼倉庫容易得多，比調整組織架構要容易得多。

• 可以保持編譯期集成這個選項。

• 可以更容易實現開發時輔助和檢查工具，可以很方便地閱讀跨模塊的代碼

• 變更風險更小，不僅僅開關回滾很快，而且開關可以靈活地定向灰度，而且一個開關的控制范圍大小也可大可小，粒度非常靈活。

• 彈性邊界更靈活，不需要因為要獨立擴縮容，就得把代碼切分出去

經常聽說的一個說法是最終是要拆分成微服務，多倉庫的。單體應用單倉庫只是一個過度形態。這會導致我們認為為啥 不 一步到位呢。 但事實并非如此，微服務和多倉庫并不一定適合所有人。 你可以用 Monorepo + Feature Toggle 用一輩子。

具體如何實踐 Monorepo + Feature Toggle 按照 https://www.branchbyabstraction.com/ 和 https://trunkbaseddevelopment.com/ 的指導去做就可以了。

第二步：管控集成類需求的代碼審查

當我們把代碼都放一個代碼倉庫里之后，立即要面臨的問題是代碼不會寫亂么？你怎么控制什么代碼寫在哪里？每一行代碼寫之前都來問你，每一行代碼寫完了都需要你來 Review 么？

所以，我們需要一種強制檢查代碼寫在了正確的位置的自動化機制。這個機制就叫“依賴管理”。對應常見的編程語言

• 如果是 TypeScript，這個叫 package.json

• 如果是 Golang，這個叫 go.mod

• 如果是 Java，這個叫 POM.xml

當我們把代碼拆分成多個包（或者叫模塊），并使得這些包（模塊）形成特定的依賴關系，就可以通過編譯器檢查控制什么代碼必須寫在什么地方，從而不需要靠人去檢查。這個依賴關系如下圖所示

• 插件：盡可能完整的實現一個獨立的功能，比如面向最終用戶的完整的頁面

• 主板：當插件與插件之間有功能上的集成需要的時候，通過繞路主板來實現，而不能直接在插件和插件之間有引用關系

這樣做的好處是可以減少 Review 的負擔。不需要盯著每一行代碼了，只需要重點盯著主板的修改就可以了。實現的步驟是

• 先決定每個插件里封裝什么的數據庫表。如果是前端模塊，則是封裝什么后端的數據接口

• 因為插件不能引用插件，所以對應的頁面和功能就會自然選擇有這些數據庫表的插件里來寫。因為寫在其他插件里的話就訪問不到了

• 然后對于需要來自多個插件數據才能實現的功能，我們通過主板來實現

比如說我們決定有一個團購插件，有一張表 GroupPurchaseCampaign 記錄了團購活動的參與商品和規則。那么要展示團購活動列表的時候，就會自然有限選擇在團購插件里來寫，因為這個插件里可以訪問這張表。這里說的“訪問”是指可以 import GroupPurchaseCampaign 這個類型的意思。插件不能 import 另外另外一個插件定義的類型，但是不意味著運行時不能訪問別的插件的數據。運行時的數據都是通的。限制的是編譯期，誰可以 import 誰。

當需要主板進來實現”集成類需求”的時候，應該如何做。分為以下三類

• 一個界面需要同時展示來自兩個插件的數據。例如商品詳情頁，需要常規商品數據，需要當前的券活動，需要當前的限時折扣活動等。在主板里把界面分成多個槽，然后不同的槽由不同的插件來實現。

• 一個操作需要多個插件的數據進行綜合決策判斷。例如計算價格的函數，需要綜合商品的原價，需要取得購物車選擇券，需要判斷是否滿減等。在主板里把價格的計算流程里留出槽，然后不同的槽由不同的插件來實現。

• 一個插件的界面里需要展示來自其他插件的數據。例如退款申請界面，需要展示商品圖片等。這個不同之處在于整個頁面絕大部分都是由一個插件自己實現的，只是在局部的地方需要其他插件的數據。所以就不值得把整個頁面都下沉到主板里去寫。實現方法是在主板里聲明一個ProductCard組件，然后這個組件由常規商品插件實現，再由退貨插件來使用用。

主板起到的作用和 C 編程里的“頭文件”的作用是一樣的，就是給模塊之間相互調用提供聲明。主板的代碼要盡可能的少，絕對不要在主板里提供 CRUD 的裸數據接口，主板里定義的是界面的槽，流程的槽，而不是直接把數據庫的原始數據暴露出去。

技術上如何實現：在一個包里提供聲明， 在 另外一個包里寫實現。 這個有兩類做法：

• 通過運行時多態來實現。在主板里定義 interface，在插件里寫實現 interface 的類的或者函數。然后在啟動的時候，做一次 “AutoWire” 的綁定操作。這個綁定最簡單的方式可以是對類型為函數指針的全局變量做一下賦值操作。也可以由 Spring 這樣的依賴注入框架來做 AutoWire。

• 通過編譯期做源代碼的復制粘貼。需要在編譯之前先對源文件做一下處理，然后再喂給編譯器。

無論是哪種具體實現技術，都不要實現成如下圖所示這樣

在插件之上 不應該有 一個額外的包（模塊）包含業務邏輯了。插件對主板的插入應該是一個 AutoWire，純機械不含業務的過程。業務編排這樣的概念一定不要出現在依賴關系的最頂層。我們已經在最底下的主板實現了所謂的“業務編排”了。

SaaS 可以把自己的功能拆解到多個插件來實現。但是經常有“按需”組裝，或者付費購買的需求。我們并不需要動態來組裝代碼來獲得“按需”組裝的產品效果。代碼可以是一份，只是通過運行時的開關來控制某些插件是否啟用。這些開關可以是配置文件，也可以是數據庫表來控制。在沒有啟用的時候，界面上完全隱藏相關的組件（就是 if/else 判斷），用戶也察覺不到這個功能的存在。付費購買其實就是付費買這個開關，也不需要像 Apple Store 那樣真的去做什么代碼下載和安裝。當然給外包公司做二次開發就是完全另外一個話題了，與本主題無關。是否打開某個插件可以是全局性的（給每個商家或者租戶啟用），也可以是“訂單”級別。一個所謂的訂單履約流程，需要組合多個插件的功能。對于每個訂單來說，都有一堆 bit 開關來決定某個插件是否啟用了，以及對應的業務數據是什么。比如 GroupPurchase + OrderSelfPickup + Order 可以組合成團購自提的訂單。訂單在此處只是一個例子，不同類型的業務有自己的領域概念。

第三步：管控規范型需求的代碼審查

有了主板加插件，Monorepo 已經切分出了多個子目錄了。每個開發者也基本上能夠知道什么需求寫在什么目錄下，哪些目錄是自己經常修改的。接下來的問題是，如果每個開發者都各寫各的，那他們之間有重復實現怎么辦？誰來避免同一個東西，被不同產品經理提出多遍，再由不同的開發者用不同的姿勢實現多變，導致浪費和返工？這個也是一個 Code Review 的問題。不能指望有一個人來 Review 每一行代碼。

解決辦法就是我們希望有一個人來“收口”，然后由這個人來保證收口之后的代碼沒有重復的實現，建立合理的抽象。如下圖所示

所謂“收口”，就是要阻止上圖中這樣的繞過“這層抽象”，去訪問“底層API”的行為。比如說，所有的編程語言都提供了 Http 調用的能力。但是我們希望封裝一個 Http Restful API 的調用 SDK。在這個 SDK 里我們統一實現重試，統一實現熔斷摘除故障節點這樣的一些功能。避免每個調用 Restful 接口的地方都重復地 try catch，重復地寫不一致地重試邏輯。那就需要有一個人來封裝這樣的庫，同時強制所有“應該使用這個庫的地方”都使用了這個庫。

實現方案要比管控集成類需求要稍微麻煩一些。集成類需求可以用包之間的依賴關系來約束什么代碼寫在哪里，規范型需求的問題是假設一個業務包，比如團購。它依賴了 Http Restful SDK，而 Http Restful SDK 又依賴了 Http 的庫。那么就意味著團購這個包通過依賴的傳遞性，也依賴了 Http 的庫。在現有的編程語言里，都無法禁止團購的包通過傳遞性依賴獲得的調用 Http 庫的權利。這個時候我們就需要通過自制 lint 工具的方式，在編譯期額外做更嚴格的依賴關系檢查。通過 lint 檢查，強迫所有訪問 Http 庫的代碼都“收口”到某個目錄里。然后我們就可以通過 Review 這個目錄的改動，確保重試邏輯只寫了一份，而不是散落到各個地方。

這樣的 lint 規則可以檢查以下類型的訪問

• 對某個 API 是否可以調用：比如 Http 庫的 API

• 對某個自定義類型是否可以調用其指定的方法：比如 Datetime 類型，或者業務上自己封裝一個 Money 類型

• 對某個 API 的某幾個參數是否可以傳值：比如組件庫中的 Button 組件提供了 style 屬性，我們不希望把這么靈活的屬性暴露出去

• 對語言和框架某些特性是否可以使用：比如 vue 文件中可以寫 style，但是我們不希望所有的目錄都可以寫 style

再舉一個例子。通過 lint 檢查，我們可以確保所有包含樣式的前端組件都寫在某個目錄下，比如說 RegularUi 和 SpecialUi。其他目錄中的組件，只能是通過組裝 RegularUi 和 SpecialUi 目錄中的組件來完成自己的設計稿還原。當然這樣就是一種“收口”。我們可以通過 Review 對 RegularUi 和 SpecialUi 這兩個目錄下文件的修改，來發現是不是有兩個開發者在嘗試實現極度類似的頁面組件，也可以促成兩個產品經理互相交流一下，是不是把兩個組件合并成一樣的行為，避免不必要的實現成本。

“收口”的代價是不可避免會出現很多一次性的需求，個性化的需求。比如優惠券的界面就是要和其他界面不一樣。因為對樣式做了收口，所以就不能直接寫在優惠券這個包里面。于是就有了 SpecialUi 這個目錄，用于寫被收口了，但是并不可復用的東西。SpecialUi 里的組件數量的多寡，體現了 Ui 不一致性的嚴重程度。如果每個頁面都不一樣，都非常有藝術感。那說明這樣的產品并不適合對樣式進行收口，就應該各寫各的，每個頁面都純手工打造。

“收口”的 lint 檢查的關鍵是要去掉對人的主觀判斷的依賴。我們不需要判斷這里來是不是一定能復用 RegularUi。我們寧愿過度收口，導致 SpecialUi 的出現，也要避免人為主觀判斷的介入。這種“過度的”收口，是規范型需求能實現自動化檢查的關鍵。一旦我們允許酌情出現一些例外的情況下，那么又變成了需要 Review 每一行代碼了。

“收口”之后的一個風險是強行抽象。明明不適合復用同一個組件的場合，仍然復用了同一個組件。導致組件變得更復雜，導致組件經常被修改。一個對策是控制組件或者函數的參數個數，參數應該盡可能地少。如果某個函數在 Monorepo 中有10處調用，但是其名為 IsVipUserPriviliged 參數僅僅在 1 處調用有傳值。那么這個 IsVipUserPriviliged 參數大概率是不應該被添加進來的，是強行抽象的產物。對于 IsVipUserPriviliged 的處理，更適合直接寫在調用的地方，而不是被寫到可復用的目錄里。

收益

在這三步都完成之后，你獲得了一個“機器人”。它幫你在每個開發者提交代碼的時候檢查代碼是不是寫到了正確的位置。 在 通過了這個機器人檢查的基礎上，你只需要關注重點的一些目錄就可以了，對其他的修改僅僅需要抽查。 這個機器人能夠像拆分了微服務一樣，確保代碼不寫亂。 同時不像微服務那樣，拆分之后就很難調整了。 因為代碼仍然一個倉庫里，只是分了目錄，隨時都可以再調整。