架構(gòu)的重要性在于日常的積累與細(xì)致打磨。無論是不斷完善我們的架構(gòu)范式，還是處理架構(gòu)老化所需的經(jīng)驗積累，都離不開日常工作的不懈努力。我們不能奢望架構(gòu)水平會在某一天突然有所飛躍。

架構(gòu)能力的提升完全依賴于日常持續(xù)的反思和精益求精的打磨。今天，我們要探討的主題是架構(gòu)老化和重構(gòu)。

架構(gòu)老化是如何產(chǎn)生的呢？在我們不斷向系統(tǒng)添加新功能的過程中，常常會遇到實現(xiàn)功能需求的方法已超出了最初設(shè)定的框架范圍，導(dǎo)致許多功能代碼脫離了框架的約束。這些散落在各處的代碼使系統(tǒng)變得支離破碎。久而久之，代碼就會老化并散發(fā)出異味。

代碼老化的跡象包括添加新功能變得越來越困難，迭代效率降低，問題不斷涌現(xiàn)，解決一個問題卻會引發(fā)多個新問題。在理想情況下，如果我們堅持以“最小化的核心系統(tǒng) + 多個相互正交的周邊系統(tǒng)”這一指導(dǎo)思想構(gòu)建應(yīng)用，那么代碼老化的情況就會大大減少。然而，這只是理想情況。

在現(xiàn)實情況下，有許多原因會導(dǎo)致架構(gòu)老化難以避免，例如：軟件工程師的技術(shù)能力不足，只注重完成功能，而不考慮項目的長期維護(hù)成本；公司缺乏架構(gòu)評審環(huán)節(jié)，系統(tǒng)的代碼質(zhì)量得不到持續(xù)有效的關(guān)注；需求理解不夠深入，最初的架構(gòu)設(shè)計無法滿足迭代發(fā)展的需要；架構(gòu)迭代不及時，導(dǎo)致大量趕時間產(chǎn)生的補丁式代碼等。

那么，我們該如何應(yīng)對架構(gòu)老化呢？這個問題可以從兩個視角來思考：一是如何重構(gòu)系統(tǒng)，使軟件重新煥發(fā)活力？二是在重構(gòu)系統(tǒng)之前，我們應(yīng)該如何進(jìn)行局部改進(jìn)？在增加新功能時又該如何考慮？

首先，讓我們先探討后者，因為重構(gòu)系統(tǒng)聽起來更像是一項系統(tǒng)性工程，而添加新功能和進(jìn)行局部調(diào)整則是日常工作中經(jīng)常發(fā)生的事情。

老系統(tǒng)怎么添加新功能

當(dāng)我們要添加新功能時，特別是當(dāng)我們加入項目組較晚且已有大量歷史代碼時，通常會將要添加的功能定位為周邊功能。在考慮周邊功能時，我們通常會著重考慮如何最小化對核心系統(tǒng)的影響，盡量減少對核心系統(tǒng)的修改。然而，這種考慮還不夠。

實際上，當(dāng)我們將視角放在周邊系統(tǒng)時，它本身應(yīng)被視為獨立的業(yè)務(wù)系統(tǒng)。這樣一來，我們自然會提出新的要求：如何讓新功能的代碼與既有系統(tǒng)解耦，盡量減少依賴關(guān)系。這里的“不依賴”有其含義。在這里，不依賴核心系統(tǒng)的意思是業(yè)務(wù)邏輯不應(yīng)該依賴于核心系統(tǒng)。新功能的大部分代碼應(yīng)該與既有業(yè)務(wù)系統(tǒng)相互獨立，只有少量橋接代碼與核心系統(tǒng)耦合。

對于任何被正交分解的周邊系統(tǒng) B 與核心系統(tǒng) A，理想情況下我們最終應(yīng)該得到三個模塊：A、B（與 A 無關(guān)的部分）、A 與 B 橋接代碼（與 A 相關(guān)的部分）。盡管 A 與 B 橋接代碼通常也會被放到 B 模塊中，但它應(yīng)盡可能小且盡可能獨立于與核心系統(tǒng)無關(guān)的代碼。理解這一點至關(guān)重要。只有這樣，我們才能保護(hù)我們的投資，最大限度地保留今天開發(fā)新功能的投入產(chǎn)出，以及在未來進(jìn)行重構(gòu)時將重構(gòu)成本最小化。

另一個重要的“不依賴”話題是是否依賴公司內(nèi)部的基礎(chǔ)庫。對于這一點，需要進(jìn)行辯證看待，不能簡單地回答是或否。完全不依賴意味著放棄生產(chǎn)力。在這里，基本的判斷標(biāo)準(zhǔn)是，成熟度越高的基礎(chǔ)庫越值得依賴。成熟度的評估依賴于個人經(jīng)驗。首先應(yīng)該評估的是模塊規(guī)格的成熟度，因為實現(xiàn)上的問題可以通過時間來解決。模塊規(guī)格是否符合預(yù)期，以及經(jīng)過了多少用戶使用的打磨，這些是評估成熟度的依據(jù)。

架構(gòu)的局部優(yōu)化

有兩種主要的方法來應(yīng)對架構(gòu)老化：重寫（局部重構(gòu)）和依賴優(yōu)化。

1. 重寫（局部重構(gòu)）：這種方法相當(dāng)于徹底移除與要添加功能相關(guān)的代碼，然后重新編寫一份新的代碼。這與開發(fā)新功能并沒有太大區(qū)別，只是在移除的代碼中可能會有一些函數(shù)設(shè)計是合理的，可以直接引用或稍作修改以使其更符合規(guī)范。然而，我們不應(yīng)該過于熱衷于進(jìn)行局部重構(gòu)。局部重構(gòu)應(yīng)該發(fā)生在你對這部分代碼的業(yè)務(wù)比較了解的情況下，比如你已經(jīng)維護(hù)了一段時間。此外，局部重構(gòu)必須確保清理干凈舊代碼，不要留下不必要的代碼。剩下的工作可以按照我之前提到的實現(xiàn)新功能的方法來執(zhí)行。
2. 依賴優(yōu)化：這種方法關(guān)注的重點不是單個功能本身的實現(xiàn)，而是該功能與系統(tǒng)之間的關(guān)系。依賴優(yōu)化實際上是對代碼進(jìn)行整體搬遷。搬遷代碼的方法類似于刪除代碼，我們需要找到與該功能相關(guān)的所有代碼。但是，我們不是刪除這些代碼，而是將它們集中到一起。我們將對系統(tǒng)的每處修改都轉(zhuǎn)換為一個函數(shù)，例如命名為 doXXX_yyyy，其中XXX是功能代號，yyyy是對這段代碼語義的描述。

核心系統(tǒng)的重構(gòu)

對于一個長期存在積弊的系統(tǒng)，要成功地完成整體重構(gòu)是非常艱難的。一開始就直接重構(gòu)核心系統(tǒng)存在著極高的風(fēng)險。首先，改動核心系統(tǒng)可能會引發(fā)全局性的變化，我們無法保證項目的交付周期。其次，由于沒有人能夠充分了解系統(tǒng)的全貌，重構(gòu)可能會過于盲目，導(dǎo)致項目執(zhí)行風(fēng)險無法控制。

確定要對核心系統(tǒng)進(jìn)行重構(gòu)時，最高優(yōu)先級是確定其邊界，也就是使用界面（接口）。最好的情況是能夠在不修改實現(xiàn)的情況下調(diào)整核心系統(tǒng)的使用界面以滿足我們的需求。周邊系統(tǒng)對核心系統(tǒng)的依賴主要分為兩類：一是核心系統(tǒng)的功能，表現(xiàn)為它提供的 DOM 接口；二是核心系統(tǒng)提供的事件，讓周邊系統(tǒng)能夠介入其業(yè)務(wù)流程。

為了確定核心系統(tǒng)需要暴露的事件集合，首先需要對所有周邊模塊進(jìn)行依賴優(yōu)化的整理，并進(jìn)行細(xì)致的分析。然后，需要將核心系統(tǒng)的 DOM 接口抽象出來。這一步比較復(fù)雜，包括將周邊系統(tǒng)對核心系統(tǒng)的依賴轉(zhuǎn)變?yōu)榻涌谝蕾?，以及審視核心系統(tǒng)功能的 DOM 接口的合理性，明確出期望的接口設(shè)計。

接下來，是最關(guān)鍵的一步。我們需要對核心系統(tǒng)的接口進(jìn)行重新設(shè)計。這一步的難點在于，一方面我們對業(yè)務(wù)的理解已經(jīng)有了長足的進(jìn)步，我們抽象的業(yè)務(wù)接口應(yīng)該更加精煉、符合業(yè)務(wù)本質(zhì)的表達(dá)方式；另一方面，需要充分預(yù)計周邊系統(tǒng)切換到新接口的成本。對于周邊系統(tǒng)來說，這是從老接口過渡到新接口的過程。

完成接口改造后，剩下的工作就相對簡單了。核心系統(tǒng)和每個周邊系統(tǒng)都彼此獨立，可以單獨進(jìn)行調(diào)整和優(yōu)化。如果覺得當(dāng)前的核心系統(tǒng)太糟糕，那就開始改進(jìn)。這樣輕松決策的原因在于，即使我們要重新編寫核心系統(tǒng)，要做的事情也很清晰，不會影響到整體。這與那些邊界不清晰的業(yè)務(wù)系統(tǒng)不同。要改動核心系統(tǒng)的代碼？不要命了嗎？