架構師日常（三）

• 2022 年 4 月 11 日
• 筆記
• architecture

架構師日常（三）

周末開始研究項目源程式碼了，這關係到一個經常被問到的問題：架構師到底應不應該寫程式碼，我來舉例說明：

成為架構師最初的幾個項目，我基本都是從寫程式碼過來的：

• 第一個項目，.NET平台，根據客戶各地區不同的業務規則模板，基於規則引擎創建靈活可訂製的查詢。這個項目核心就是規則引擎和動態SQL腳本，所以我採用了正則表達式，正則這一塊兒交給了我們上海那邊的一位年輕同事，他學習能力很強，基本80%的規則引擎內容都是他開發完成的。但是這個工作開始的階段，我還是需要做一個簡單的原型跟客戶團隊和我們團隊的業務負責人解釋規則引擎和動態查詢是如何工作的。

• 第二個項目，基於WordPress做一個Headless的內容管理系統CMS應用，用來管理數字資產，後台存儲使用亞馬遜雲的S3對象服務，我寫的程式碼原型包括：

  • 搭建WordPress曝露RESTful API
  • 實現跟企業單點登錄SSO的集成
  • 實現S3文件對象的上傳、下載（其中下載使用即時簽名URL的方式保證下載URL被他人拿到無法訪問）

• 第三個項目，因為第二個項目的原因我們又接到了一個企業級業務戰略資產的CMS項目。這回要求使用Drupal開發，我寫的程式碼原型包括：

  • Drupal頁面及服務的模組化開發方法演示
  • 趨勢圖的動態生成（類似Gartner的技術趨勢S曲線圖）

• 後面的項目包括：數據上傳數據湖、SAP API系統集成、AWS和Azure的無服務REST API、NoSQL資料庫使用、ElasticSearch搜索引擎的使用等等都寫了不少的程式碼。

架構師寫程式碼與開發人員寫程式碼當然是不同的，架構師需要從架構的角度審視程式碼，比如是否滿足可擴展性、性能、安全等方面的要求。而當這些程式碼下發給開發人員使用時，也就保證了架構滿足類似方面的需求。

那架構師還需要參與哪些程式碼工作？包括但不限於：

• 開發運維Pipeline的配置，比如我現在的項目可能就涉及到CI/CD Pipeline要實現參數化和Mono Repository（單一程式碼倉庫）的模式。
• 程式碼評審，業務程式碼還好，主要是一些技術性程式碼。說小了包括如何操作字元串文本，說大了到如何集成數據湖等等，各種程式碼的技術性方面都要多少看一看。但不需要每個程式碼都看，也不需要時時看。比如兩個Sprint下來檢查一次，主要看看是否按照架構設計的方向在走，用的庫有沒有技術性問題比如性能方面，是否健壯，有沒有維護團隊，許可有沒有問題等等。其實做事的方法很多，主要是架構師或高級架構師在組織層級的企業級架構經驗比較多，知道很多企業級的技術合規性問題如何解決，但是到下面的架構師或開發人員，因為跟企業上層的企業架構距離比較遠，做事的時候難免有偏差。比如企業在AWS雲上的無服務計算策略是使用API Gateway + Lambda實現，而團隊跟新，使用ECS + Fargate實現，這就跟企業架構定下的規則有所衝突，而在後期評審、運維上就會被質疑，因為從成本上考量確實前者比後者更有優勢，不過也要視場景而定，畢竟不同的服務有不同的限制。
• 程式碼重構，這個是我強烈建議架構師進入既有項目的時候需要考慮是否需要重構，如何重構，究竟是需要Re-Factoring還是Re-Platform或者Re-Arch。如果你進入項目的時候沒發現平台或架構問題，一個發布下來再做可能就已經晚了。