如何避免新代碼變包袱？阿里通用方法來了！

阿里妹導讀：什麼是設計？什麼是架構？從零開始創建一個新的系統，新寫的每行代碼均可能成爲明天的歷史包袱？如何能有效的在遺留代碼上工做？今天，阿里資深技術專家輝子爲咱們帶來NBF框架下軟件工程架構設計通用方法論，值得細細品讀。

Note：本文討論的是基於服務化前提下的通用軟件工程架構方法論，並未涉及到微觀設計或架構的具體細節。

前言

即便代碼多年的人都會對這兩個問題有點蒙圈：什麼是設計？什麼是架構？

從單詞上看：設計是Software Design，架構是Software Architecture；分別對應的做者是：Designer和Architect：

• Architect都是Designer，但Designer未必是Architect。正如全部的架構設計都是設計，但設計未必是架構設計；
• Design關注微觀代碼(inside component)，Architecture關注宏觀軟件結構(between components)；
• Architect應該都是從Designer成長起來的。畢業了用code編寫軟件；成長了用ppt設計軟件；
• 只會用ppt設計，但代碼寫得很差的Architect都是假的Architect；
• Architecture裏聽到比較多的詞語：Serverless、FAAS、Microservice、multi-layer、Event driven、OSGI、NBF......
• Design裏聽到比較多的詞語：SOLID、 DDD、正交設計、Design Pattern；
• 搞不清SOLID，也不可能把軟件的層次分好，也沒法理解什麼是OSGI的價值；
• 好的Designer是通往好的Architect的必經之路。

服務化架構的基本原則

New System

從零開始創建一個新的系統，有幾個特徵：

• 歷史包袱小
• 上下文簡單
• 設計的約束小
• 新寫的每行代碼均可能成爲明天的歷史包袱

因爲調用方尚未，新系統能夠比較完美的執行咱們預想的架構設計，可是切記，最後那行纔是最重要的那行：不要讓今天的代碼成爲明天的歷史包袱，新的每行代碼都在書寫歷史。

上圖的1，2，3，4表明新建系統的順序：

1. 由「相」抽象出「心」：先思考，那麼多的業務場景下「相」，共同的特徵「心」是什麼。並反向用更多的相去驗證心。
2. 將「心」具象成領域模型：關注領域模型(Domain Model)，解耦數據模型(Persistence Model)：將TUNNEL SPI化。
3. 將領域模型中的依賴SPI化：解耦對外部系統的依賴，反轉依賴控制權。
4. Mock全部spi實現，確保「心」領域模型包裹的單元測試徹底經過
5. 實現TUNNEL BUNDLE：設計數據模型（Persistence Model），關注「存」，「取」不關注領域模型。
6. 實現依賴SPI適配BUNDLE：鏈接真實依賴服務。
7. 包裝domain service：模型相關，業務無關。
8. 根據業務需求組合/編排domain service成爲scenario bundle或者業務SOP。

Working on legacy

對於一個軟件工程師來說，寫代碼最痛苦的事情莫過於coding on legacy，但同時又給了咱們各類說辭：

• 這些代碼太爛了，改起來太費勁【須要更多人】
• 這事作不到，由於之前系統架構問題致使的【責任不在我】
• 通過個人修改，如今已經好不少了，工單數量大批降低【我功勞顯著】
• 知不知道：接手你代碼的人其實也在重複說上述3件事情

如何能有效的在遺留代碼上工做，業內有本很是不錯的書，叫"Working Effectively with Legacy Code",值得精讀：

因此我這裏的標題可能不許確，我要討論的更可能是"遺留代碼的重構"，何時咱們開始討論須要把現有系統重構：

• 代碼確實腐化到沒法正常維護，或者新加一個需求代價很大；
• 目前代碼的技術架構知足不了下一步業務的發展；
• 不少特性已經下線做廢，卻跟有用的代碼藕斷絲連；
• 業務邏輯隨着發展分散到不一樣的應用裏，界限不清；
• 專家級的未雨綢繆，着眼將來的規劃和新技術的應用；
• 換老大了，須要立新的flag。

架構的基本原則依然是上面那幅圖。但上下文的不一樣，咱們的發力點和優先級有明顯的區別。阿里整個體系裏的依賴關係錯綜複雜，要對阿里環境下的系統作重構是件絕對謹小慎微的事情。爲了完成在這麼複雜體系下的架構及代碼重構，咱們必須有條不紊的分離關注點以及一如既往的堅持軟件卓越。

聚焦與收斂上游調用

解耦下游依賴

以服務爲單位切換

老系統下線

通過一步一步的分解，legacy系統已經徹底被重構，而且具有隨時切換的準備。這裏我給幾個建議：

1. 先把老實現做爲API的默認實現，新的實現做爲老的實現的降級實現，並使用策略分流一部分流量（具體比例跟團隊信心相關）；
2. 對於有業務需求變動的部分應儘快實如今新的實現裏，並將新實現做爲API的默認實現，老實現做爲新實現的降級實現，策略應該是即時降級，也就是新實現出現問題馬上降級到老實現；
3. 運行一段時間沒有問題後，講全部默認實現切換爲新實現，並將老實現做爲新實現的降級實現；
4. 其實這時就算全部切換完畢：老實現能夠永遠做爲新實現的降級實現，也就是隻要我升級一次服務，上一次成功版本就能夠做爲此次的降級實現，這樣，線上問題回滾就是秒級的。

總結

本文基於藉助NBF提供的遠程多態，服務編排等能力下基礎資料，商品，組網等系統新建，重構的經驗及方法論總結。僅供遇到架構重構，解耦等問題困擾的技術團隊參考。

Note：本文全部圖形出自玉簡

---

本文做者：輝子

閱讀原文

本文來自雲棲社區合做夥伴「阿里技術」，如需轉載請聯繫原做者。