軟件開發從來不是一次寫完就結束的事情。需求會變，技術會升級，團隊會流動。一套代碼能跑多久、改起來順不順手、新同事接手快不快，這些往往比“第一次寫出來”更重要。高質量軟件設計與設計模式，談一談從原則到實踐的幾條路徑，設計模式不是銀彈，但理解背后的原則，能幫我們少走一些彎路。

一、什么算“高質量”的軟件

很多人把“能運行”等同于“好”。其實軟件質量分內外兩層：外部質量是用戶看到的功能正確、響應快、不崩潰；內部質量是代碼可讀、可維護、容易改。外部質量靠測試驗證，內部質量靠設計保障。

判斷內部質量有幾個簡單標準：新同事看代碼能不能快速理解？改一個功能會不會牽連一堆地方？加新需求時是“加新代碼”還是“改老代碼”？如果答案不樂觀，說明設計需要調整。

二、幾個基礎的設計原則

依賴反轉：高層模塊不應該依賴低層模塊，兩者都應該依賴抽象。比如業務邏輯層不應該直接依賴具體的數據庫訪問類，而是依賴一個數據訪問接口。這樣換數據庫時，業務代碼不用改。

開放-封閉：對擴展開放，對修改封閉。需求來了，盡量加新類新方法，而不是改老代碼。這就要求設計時預留擴展點，比如用接口、抽象類把可變部分隔離開。

里氏替換：子類應該能替換父類，程序行為不變。如果正方形繼承自矩形，而矩形的寬高可以分別修改，正方形就做不到，這種繼承關系就有問題。

單一職責：一個類只做一件事。看類名就能猜出它的功能，如果描述不清或者有“和”字，很可能職責過多。拆開之后，每個模塊更清晰，改其中一個不影響其他。

不要重復自己：同樣的邏輯只寫一次。重復不僅浪費，更是隱患——改一個地方忘了改其他地方，bug就來了。抽取公共方法、用模板方法、繼承、組合，都是消除重復的手段。

三、設計模式：常見場景的解法

適配器模式：當系統需要對接一個外部接口，而接口的格式、調用方式與內部不一致時，加一層適配器做轉換。比如對接第三方支付接口，每家參數不同，適配器封裝差異，業務層只調用統一方法。

策略模式：一個功能有多種算法，需要動態選擇。比如工資發放，正式員工、兼職員工、外包員工的計薪方式不同。策略模式把算法封裝成獨立的類，運行時切換，避免if-else堆砌。

工廠模式：當對象的創建過程復雜、或者需要根據配置選擇不同實現時，用工廠來創建。簡單工廠、工廠方法、抽象工廠，本質都是把“怎么創建”和“誰來使用”分開。

單例模式：一個類只需要一個實例，比如配置管理、線程池。實現時注意線程安全，懶加載還是餓漢，取決于場景。但單例容易隱藏耦合，用多了會讓代碼之間偷偷依賴，反而破壞設計。

模板方法模式：父類定義算法骨架，子類實現具體步驟。比如數據導出，流程是：查數據、轉格式、寫文件。父類寫好流程，子類實現“怎么查”“轉成什么格式”，既復用代碼又留出變化點。

裝飾者模式：不修改原類，動態給對象添加功能。比如數據源讀寫，業務增長后需要加緩存、加日志、加讀寫分離。裝飾者一層層包上去，每個功能獨立，需要哪些組合哪些。

四、重構：讓代碼慢慢變好

軟件退化是常態。需求不斷加，改的人換了一茬又一茬，代碼慢慢就亂了。重構不是推翻重來，是小步快跑，每次改一點，始終讓系統處于可運行狀態。

常用的重構手法：抽方法解決大函數，抽類解決大對象，抽父類提高復用，用設計模式降低耦合，建立分層結構。關鍵是每一步都要驗證，不能積累到受不了再動手。

五、小步快跑：降低風險的方式

很多項目不敢改設計，是因為擔心改壞了。小步快跑的思路是：每次只做一小步，每一步都有明確的目標和驗證方法，確保當前版本比上一版本更好。

比如加一個新需求，先寫測試，再改代碼；或者先重構讓代碼易于擴展，再寫新功能。兩種做法交替，既能推進功能，又能改善結構。這和先設計后編碼并不矛盾，只是把設計分成了多次迭代。

六、防止軟件退化的幾個習慣

一是寫清楚注釋，不僅寫“做了什么”，更要寫“為什么這么做”。二是保持代碼整潔，發現“壞味道”就順手改一下，不要等到積重難返。三是團隊統一編碼規范，減少理解成本。四是定期進行代碼評審，不僅找bug，也看設計是否合理。

軟件設計不是一次性的藝術，而是持續演進的過程。工程師高培認為設計模式是工具箱里的工具，原則是選工具的準則，重構是保持工具箱整潔的方法。三者結合，才能讓代碼在變化中保持優雅。

審核編輯 黃宇