架構師日常（三）
週末開始研究專案原始碼了，這關係到一個經常被問到的問題：架構師到底應不應該寫程式碼，我來舉例說明：
成為架構師最初的幾個專案，我基本都是從寫程式碼過來的：
-
第一個專案，.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。如果你進入專案的時候沒發現平臺或架構問題，一個釋出下來再做可能就已經晚了。