羅哥德
天天寫業務代碼確實不一定能成為架構師，但是寫不好業務代碼肯定不能成為架構師！
架構師寫代碼的時間不超過工作時間的40%，剩餘的大部分時間主要與業務相關，每天參加各種各樣的KT會，只有徹底的理解了業務需求，才能設計好一套擴展性好，穩定性好，性能優異的架構！
不過大多數架構師還是先以寫代碼做起的，不是說實現需求就是好代碼，後期的擴展，用戶量激增對於系統的要求等都要考慮清楚！
那麼架構師通常需要哪些技術棧呢？
1，需求建模，流程圖：良好的流程圖模型是整個項目循序推進的一個導向，也是合理分配任務的好方法！
2，業務抽象：面向對象的思想，將需求抽象為一個個關鍵對象，一張張表，一對多，多對多等關係梳理清楚，這個時候就已經要注意後期業務擴展，技術擴展等因素！
3，技術選型：前後端分離？微服務框架（spring boot？dubbo）？服務間通信方式（TPC，HTTP，MQ）？批處理服務？緩存選擇，消息中間件選擇？日誌收集與分析，數據存儲（mysql分庫分表？mongo），項目持續集成部署！
4，重難點突破：流程如何驅動？分佈式事務如何保證數據一致？服務間通信的安全問題？整個系統的可承載量！
5，任務分配，萬事大吉：架構師基本上不寫代碼，設計多於建造，將任務合理的分配也是架構師需要考慮的東西，集成敏捷開發等，掌控整個項目的進度，直至整個項目的交付！
架構師真的不怎麼寫代碼，但是各方面能力卻要要求很高，想要當架構師，還是先從寫業務代碼開始吧！
此生唯一
這也是大部分程序員一直困惑的問題，因為他們心裡有數，光靠公司裡寫業務代碼，是遠遠不能成為架構師的。
好的架構師是什麼樣的
但是，一定要明白一點 好的架構師一定對公司項目的業務有比較深的瞭解，架構師不僅僅是技術上的選型，更要結合業務去利用技術。因為技術都擺在這個世界，架構師你不可能去發明這麼多中間件，但是卻可以根據需求組裝中間件。
如何成為架構師
因此，如果程序員想成為架構師，本人認為一定不能因為寫業務代碼而磨滅這個想法，寫業務代碼也可以提升自己的業務水平，對一款產品會有自己的理解，並且可以學習這套產品的架構師是什麼樣的架構思路。
然後自己在技術層面也要多向架構師去靠攏，這就意味著自己在工作之餘要不斷自學架構師應該具備的技術，而不能只靠公司裡工作的時間去學習去提升，這不現實。
