我們一起聊聊架構老化與重構
架構的重要性在于日常的積累與細致打磨。無論是不斷完善我們的架構范式，還是處理架構老化所需的經驗積累，都離不開日常工作的不懈努力。我們不能奢望架構水平會在某一天突然有所飛躍。
架構能力的提升完全依賴于日常持續的反思和精益求精的打磨。今天，我們要探討的主題是架構老化和重構。
架構老化是如何產生的呢？在我們不斷向系統添加新功能的過程中，常常會遇到實現功能需求的方法已超出了最初設定的框架范圍，導致許多功能代碼脫離了框架的約束。這些散落在各處的代碼使系統變得支離破碎。久而久之，代碼就會老化并散發出異味。
代碼老化的跡象包括添加新功能變得越來越困難，迭代效率降低，問題不斷涌現，解決一個問題卻會引發多個新問題。在理想情況下，如果我們堅持以“最小化的核心系統 + 多個相互正交的周邊系統”這一指導思想構建應用，那么代碼老化的情況就會大大減少。然而，這只是理想情況。
在現實情況下，有許多原因會導致架構老化難以避免，例如：軟件工程師的技術能力不足，只注重完成功能，而不考慮項目的長期維護成本；公司缺乏架構評審環節，系統的代碼質量得不到持續有效的關注；需求理解不夠深入，最初的架構設計無法滿足迭代發展的需要；架構迭代不及時，導致大量趕時間產生的補丁式代碼等。
那么，我們該如何應對架構老化呢？這個問題可以從兩個視角來思考：一是如何重構系統，使軟件重新煥發活力？二是在重構系統之前，我們應該如何進行局部改進？在增加新功能時又該如何考慮？
首先，讓我們先探討后者，因為重構系統聽起來更像是一項系統性工程，而添加新功能和進行局部調整則是日常工作中經常發生的事情。
老系統怎么添加新功能
當我們要添加新功能時，特別是當我們加入項目組較晚且已有大量歷史代碼時，通常會將要添加的功能定位為周邊功能。在考慮周邊功能時，我們通常會著重考慮如何最小化對核心系統的影響，盡量減少對核心系統的修改。然而，這種考慮還不夠。
實際上，當我們將視角放在周邊系統時，它本身應被視為獨立的業務系統。這樣一來，我們自然會提出新的要求：如何讓新功能的代碼與既有系統解耦，盡量減少依賴關系。這里的“不依賴”有其含義。在這里，不依賴核心系統的意思是業務邏輯不應該依賴于核心系統。新功能的大部分代碼應該與既有業務系統相互獨立，只有少量橋接代碼與核心系統耦合。
對于任何被正交分解的周邊系統 B 與核心系統 A，理想情況下我們最終應該得到三個模塊：A、B（與 A 無關的部分）、A 與 B 橋接代碼（與 A 相關的部分）。盡管 A 與 B 橋接代碼通常也會被放到 B 模塊中，但它應盡可能小且盡可能獨立于與核心系統無關的代碼。理解這一點至關重要。只有這樣，我們才能保護我們的投資，最大限度地保留今天開發新功能的投入產出，以及在未來進行重構時將重構成本最小化。
另一個重要的“不依賴”話題是是否依賴公司內部的基礎庫。對于這一點，需要進行辯證看待，不能簡單地回答是或否。完全不依賴意味著放棄生產力。在這里，基本的判斷標準是，成熟度越高的基礎庫越值得依賴。成熟度的評估依賴于個人經驗。首先應該評估的是模塊規格的成熟度，因為實現上的問題可以通過時間來解決。模塊規格是否符合預期，以及經過了多少用戶使用的打磨，這些是評估成熟度的依據。
架構的局部優化
有兩種主要的方法來應對架構老化：重寫（局部重構）和依賴優化。
- 重寫（局部重構）：這種方法相當于徹底移除與要添加功能相關的代碼，然后重新編寫一份新的代碼。這與開發新功能并沒有太大區別，只是在移除的代碼中可能會有一些函數設計是合理的，可以直接引用或稍作修改以使其更符合規范。然而，我們不應該過于熱衷于進行局部重構。局部重構應該發生在你對這部分代碼的業務比較了解的情況下，比如你已經維護了一段時間。此外，局部重構必須確保清理干凈舊代碼，不要留下不必要的代碼。剩下的工作可以按照我之前提到的實現新功能的方法來執行。
- 依賴優化：這種方法關注的重點不是單個功能本身的實現，而是該功能與系統之間的關系。依賴優化實際上是對代碼進行整體搬遷。搬遷代碼的方法類似于刪除代碼，我們需要找到與該功能相關的所有代碼。但是，我們不是刪除這些代碼，而是將它們集中到一起。我們將對系統的每處修改都轉換為一個函數，例如命名為 doXXX_yyyy，其中XXX是功能代號，yyyy是對這段代碼語義的描述。
核心系統的重構
對于一個長期存在積弊的系統，要成功地完成整體重構是非常艱難的。一開始就直接重構核心系統存在著極高的風險。首先，改動核心系統可能會引發全局性的變化，我們無法保證項目的交付周期。其次，由于沒有人能夠充分了解系統的全貌，重構可能會過于盲目，導致項目執行風險無法控制。
確定要對核心系統進行重構時，最高優先級是確定其邊界，也就是使用界面（接口）。最好的情況是能夠在不修改實現的情況下調整核心系統的使用界面以滿足我們的需求。周邊系統對核心系統的依賴主要分為兩類：一是核心系統的功能，表現為它提供的 DOM 接口；二是核心系統提供的事件，讓周邊系統能夠介入其業務流程。
為了確定核心系統需要暴露的事件集合，首先需要對所有周邊模塊進行依賴優化的整理，并進行細致的分析。然后，需要將核心系統的 DOM 接口抽象出來。這一步比較復雜，包括將周邊系統對核心系統的依賴轉變為接口依賴，以及審視核心系統功能的 DOM 接口的合理性，明確出期望的接口設計。
接下來，是最關鍵的一步。我們需要對核心系統的接口進行重新設計。這一步的難點在于，一方面我們對業務的理解已經有了長足的進步，我們抽象的業務接口應該更加精煉、符合業務本質的表達方式；另一方面，需要充分預計周邊系統切換到新接口的成本。對于周邊系統來說，這是從老接口過渡到新接口的過程。
完成接口改造后，剩下的工作就相對簡單了。核心系統和每個周邊系統都彼此獨立，可以單獨進行調整和優化。如果覺得當前的核心系統太糟糕，那就開始改進。這樣輕松決策的原因在于，即使我們要重新編寫核心系統，要做的事情也很清晰，不會影響到整體。這與那些邊界不清晰的業務系統不同。要改動核心系統的代碼？不要命了嗎？
