爲何不少程序員沒有升級到架構師？

爲何不少程序員沒有升級到架構師？
對咱們程序員來講，發展的途徑要麼是走管理崗，從開發升級到項目經理甚至是部門經理；要麼走技術升級路線。不過在技術路線方面，沒法升級到架構師的程序員不在少數。一方面，在很多公司的高級開發崗位上，沒法讓程序員實踐甚至接觸到架構師的技能，另外一方面，有很多程序員甚至不清楚架構師所須要掌握的技能和升級途徑。因此從結果上來看，至少有5成的程序員止步於「高級開發」的程度，這是很是使人惋惜的。

我這幾年一直努力地從高級開發升級到架構師，目前雖然職位上沒達到，但好歹多少也能幹些架構師方面的活了。在本文裏，將結合我自身和其它一些程序員的經歷，分析很多程序員沒法升級到架構師的廣泛緣由，由此向你們展現從高級開發升級到架構師的難點，並在此基礎上給出相關的升級建議。

一、不少程序員在平常工做裏沒法接觸到架構師的技能
大多數的程序員能在工做中接觸到高級開發的技術，因此從初級開發升級到高級開發，難度並不大，但架構師就不一樣了。

好比在外包公司裏，程序員大可能是作重複勞動，業務變了，但用到的技術仍是增刪改查。或者在一些規模比較小的公司，項目組出於成本和質量監控的考慮，也未必會讓程序員從事架構方面的工做。哪怕在一些技術含量比較高的互聯網公司，出於業務封裝的角度，一些高併發高可用的實現每每被封裝在方法裏，程序員僅僅是經過調用方法實現功能，未必能在代碼層面，顯式地看到架構方面的技能。

接觸不到相關技能，單靠看視頻看資料積累起來的技能，在面試過程當中每每會不堪一擊，從而沒法應聘架構師的崗位，這反過來制約了程序員向架構師發展的腳步。

我有時候在面試高級開發的時候，會深刻問些架構方面的問題，好比我問，大家系統裏，模塊間的通信用的是什麼組件 ，很多高級開發甚至是一頭霧水，或者在他們眼裏，更多的是調用方法實現功能。

二、很多程序員每每會深挖單機版的技能
不少工做中得過且過的程序員，在實現的功能經過測試之後，或許就無所事事了，並且這類程序員不在少數，在小公司或外包公司裏，這類程序員每每會更多，說實現的，他們的競爭力和從培訓班裏出來的程序員沒什麼兩樣，或許就更熟悉業務背景。

或者有些程序員雖然上進，但會深挖單機版的技術細節，好比我問String對象的== 和equals方法有什麼差異，或者，JVM虛擬機調優有哪些實踐要點，此類回答他們會回答很是到位。這當然要比純粹會寫代碼的程序員要好，但此類技能頂了天只能算高級開發的技能。若是在升級時過分追求這方面的技能，無異於緣木求魚。

三、列舉架構師平時要乾的活，確實和高級開發有差距
上文是從客觀和主觀兩個方面，講述了架構師升級的難處，在講述升級方法前，咱們先來看下架構師究竟要幹什麼活，以此來明確努力的方向。

一、須要搭建高可用的框架，好比就拿最簡單的搭建數據庫服務來講，得考慮若是一臺MySQL服務器宕了，如何保證業務切換到另一臺機器上。

二、須要考慮高併發的因素，從這個點展開，架構師至少須要會用nginx，mycat，netty，redis之類的工具，以及考慮搭建實現負載均衡的集羣。

三、須要把設計好的架構部署上線，或者哪怕上線動做是由運維來作，但架構師至少要知道如何把nginx集羣等組件部署上線的活，由此架構師須要瞭解必須的linux命令和腳本，以及瞭解jenkins之類的部署工具。

四、上述技能不是簡單會用便可，若是在開發部署和運行過程當中由問題，架構師得負責解決。這就要求架構師不能僅僅靠看視頻知道如何搭建系統，更得具有針對netty等組件的debug能力，還得能經過看日誌，知道集羣的運做狀況，若是集羣出了問題，還得知道如何快速解決。

五、不能僅僅關注技術，更得結合業務，把諸如搶紅包之類的需求經過架構實現，這就要求架構師得知道各類組件的優劣，以此能選型並設計方案。

從上述對架構師的需求來看，從高級開發升級到架構師很難，也在情理中了。

四、從運維入手，熟悉架構師的入門技能
升級到架構師很難，但絕非不可能，對於高級開發而言，從運維入手，或許能熟悉架構師的技能。

一、好比先從ant腳本，jenkins腳本和linux shell腳本入手，能知道系統的部署方式，以及熟悉必備的linux調試技能。

二、經過觀察nginx或dubbo或zookeeper配置文件，瞭解各組件的運做方式，並能經過這些瞭解高併發高可用系統裏負載均衡和失效轉移等配置方式。

三、能夠觀察線上相關的日誌，瞭解系統部署的狀況，以及從架構層面瞭解諸多組件間的關聯。

在上述步驟裏提到的腳本和日誌，在平時工做中只要上點心，應該能夠看到，或者咱們能夠和運維人員多交流請教，上述組件部署和配置的知識也不難知道。在這個過程當中，暫時沒涉及「修改配置」和「搭建組件」等技能，畢竟這屬於熟悉階段。

五、多解決實際問題，瞭解組件的關鍵配置，並瞭解組件的底層代碼
程序員在熟悉基本的部署和架構方面的技能之後， 就能夠參與解決一些實際的問題了。在公司裏，測試和上線階段出現的問題不能算少，其中也會包含不少和架構相關的問題，好比kafka沒配好，致使消息積壓，或者dubbo超時時間配置過長，致使調用鏈路超時失效，或者再如redis超時時間過長，致使OOM異常。相似問題的種類五花八門，只有想不到的，沒有不可能出現的。

剛開始，程序員能夠跟在資深人員以後查問題，或者找到問題後，再手動覆盤一下，學習架構師分析和解決問題的入手點，一來二去，必定能熟悉組件的配置，並瞭解組件的底層代碼，更能熟悉配置各類框架組件的實施方案。

這個階段依然屬於「見習」，但至少能從實踐角度，掌握架構師所需的技能。對比本身經過看視頻，以閉門造車的方式積累架構師的技能，經過上述步驟獲得的相關經驗來源於實際，無疑值錢得多。

六、必要時，得經過跳槽，爭取架構師的實踐機會
其實在小公司甚至是外包公司裏，都有機會了解甚至實踐上文提到的架構師相關技能。程序員經過上述步驟掌握架構師的相關技能後，若是再加以實踐機會，就能很快成爲名副其實的架構師。

這種實踐機會在大公司裏不難找，但在小公司裏或許就很少了，不過也沒關係，這時若是再出去面試架構師的崗位，基本上就沒什麼難度了。咱們來看下架構師的面試問題。

一、如何部署nginx（或其它組件），從而實現高可用？

二、Redis集羣裏，容災通常是怎麼作的？

三、Kafka消息隊列裏，如何實現消息重複？如何確保消息不被重複消費？

四、或者是問底層的問題，好比說下netty裏的讀寫索引工做方式。

或者在目前階段，你們未必能回答好上述問題，但一旦在運維層面瞭解過組件的搭建方式，或者經過排查實際問題了解過組件的運做和交互方式，再專研下相關底層代碼，哪怕沒太多的架構師實踐經驗，此類問題也不難回答。

或許一個沒太多實踐經驗的架構師，在公司裏日子會很難過，能夠會讓領導和組員感受實踐經驗不足，但大多數架構師也都是經過實踐一點點積累相關經驗的，在這個階段裏，若是再肯多聽多看多問題，升級到資深架構，就指日可待了。

七、總結，升級到架構師後，會有更多的機會
其實對於咱們作IT的人來講，升級到架構師未必是惟一的發展途徑，但不是每一個人都適合搞管理。若是走的是技術加成路線的話，從架構師到技術專家，或許是一條比較合適的發展途徑。

對於高級開發而言，或許真有30歲或35歲現象，畢竟高級開發所需的技能很容易被畢業生或培訓生掌握，年紀一大了就沒競爭優點了，但正是由於升級到架構師不是那麼容易，到35歲時，或許還有競爭的能力。

並且，一旦升級到架構師，退則能夠找個小公司作技術負責人，以求小富即安，從而不會像高齡碼農那樣被淘汰；進則能夠再到大廠裏去磨練一番，而後再經過各類途徑拓展影響力，那麼真就能夠說成爲技術大牛了。反之，若是止步於高級開發，雖然也能經過跳槽提高工資，但格局始終沒法像架構師那樣開闊了。