分享我如何在7年時間裏成長爲阿里Java架構師（附學習路線圖）

導讀：

1. 架構師應不該該寫代碼
2. 爲何別人的系統老是那麼爛
3. 成爲架構師最困難的門檻是什麼？
4. 如何更高效的學習？

1.架構師應不該該寫代碼

合格的程序員對於明確分配的任務會完成的很好，可是大部分狀況下「架構」這個詞意味着架構師並不會涉及太多細節，架構圖和代碼實現之間總仍是有些距離，你沒法保證全部人都會正確的理解你的設計，或者是程序員寫代碼時遇到障礙時會馬上想出足夠優雅的解決方案。

在我看來，寫代碼的架構師更像是在作後勤保障的工做：在代碼中第一時間發現可能存在的問題，向其餘人提出警告，或是給予其餘人改進的意見，必要的時候或是給其餘人演示一下正確的姿式。

大部分狀況下我做爲架構師並不須要攬下「核心模塊」開發這種工做，畢竟我能調配的時間太零散了，效率難以保證，不少人在專一的狀況下比我作的好不少，我只須要保持大局觀須要適度參與就能夠了。

總的來講，架構師和程序員在某些方面上有點像產品經理和用戶的關係，大部分程序員並不會主動告訴你他們想要什麼、哪裏須要優化，甚至本身也不知道這些。想要作出好的產品，捷徑之一就是跟用戶作一樣的事情。

2.爲何別人的系統老是那麼爛

不少程序員解決問題的能力很強，說要解決一個什麼問題，下午就能寫出幾百行代碼把功能實現了。可是作出來的東西有種少考慮了什麼東西的感受。大部分程序都能實現功能，可是若是把「時間」這個也做爲一個考慮的維度的話，就會意識到一個合格的項目須要考慮更多的東西：更通用的使用方式、易於理解的文檔、簡單而易於擴展的設計，等等。

不少公司應該都會有一些遺留系統，它們龐大、笨重、難用、幾乎沒法維護，全部人都在抱怨這些系統，而且天天都在千方百計換掉那些遺留系統。可是一段時間過去以後，又會發現身邊的新人又開始吐槽當時替代遺留系統的那個系統了。

「大多數系統當初都很好使，功能當時夠用，擴展性看起來也能夠，可是這些系統都是開發的人離職以後變壞的。」

3.成爲架構師最困難的門檻是什麼？

不少人自稱架構師的人跟你講一個架構時簡直口若懸河，各類技術名詞像是說相聲同樣從他嘴裏說出來，三句話不離高併發大數據，可是稍微追問一下，就會發現不少基本概念的缺失，例如自稱精通高併發的人說不清楚他所謂的高併發系統的瓶頸在哪裏，自稱精通架構設計的人說不明白他的系統怎麼保證高可用，自稱超大數據量的系統實際上只有不到100萬條數據，等等。

架構師雖然聽起來很高大上，但本質上仍然是工程師，不是科學家，也不是忽悠人的江湖騙子。學習再多，也須要實踐落地。設計架構方案更多的是在作一些抽象和權衡：把複雜的需求抽象成簡單的模型，從功能、性能、可用性、研發成本等等方面規劃如何構建一個系統，這些內容須要更多的實踐練習。

4.如何更高效的學習？

大多數人天天能留給本身學習的時間有限，這個階段如何提高學習效率就成了要解決的重點。

說說本身提高學習效率的心得，其實很是簡單：體系化的學習。

在重複了幾回痛苦的學習-梳理過程後，再去看一些獨立的文章或者資料每每會事半功倍，由於能在體系內找到相對應的知識，甚至有時候一本書裏一頁只須要看一句話，點破那層窗戶紙，就能夠掌握新的知識。

跟不少人同樣，剛畢業時我以爲做爲程序員，只要努力，加上少量天賦即可以得到一些成績。

工做一段時間後，對本身和其餘人的認識也愈來愈清晰，逐漸的發現程序員之間的差距或許比人和猴子之間的差距還大，接受這個事實這讓我鬱悶了好久。

再過一段時間，發現本身已經可以客觀的評價本身的能力，也意識到了距離並非那麼重要，只要想辦法跑的更快，就足夠了。

5.快速成爲架構師的學習路線
在此我向你們推薦一個架構學習交流羣。交流學習羣號：575745314 裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多

分佈式學習路線

微服務學習路線

性能優化學習路線

經典設計模式與源碼分析

開發必備工具

動手實踐項目

以上五大知識體系是我從業多年總結出來的經驗，都是當前最主流的技術。想學習這些技術的朋友能夠加羣。