前言
用了6年的時間成為阿里架構師，一步一步走到了現在，中途也想過轉換行業，也去了解過別人領域比較好的技術，也想過要轉其他的語言，但是最后還是堅持下來走Java這條路，希望我的經歷可以幫助到后來的人，要是覺得對你有是幫助的話，可以點贊關注一下，
當然也整理了今年最新的知識點和面試題，需要的朋友可以點擊：這個，點這個！！，暗號：csdn，
目錄
- 前言
- 架構師應不應該寫代碼
- 為什么別人的系統總是那么爛
- 成為架構師最困難的門檻是什么？
- 如何更高效的學習？
- 快速成為架構師的學習路線
架構師應不應該寫代碼
合格的程式員對于明確分配的任務會完成的很好，但是大部分情況下“架構”這個詞意味著架構師并不會涉及太多細節，架構圖和代碼實作之間總還是有些距離，你無法保證所有人都會正確的理解你的設計，或者是程式員寫代碼時遇到障礙時會立刻想出足夠優雅的解決方案，
在我看來，寫代碼的架構師更像是在做后勤保障的作業：在代碼中第一時間發現可能存在的問題，向其他人提出警告，或是給予其他人改進的意見，必要的時候或是給其他人演示一下正確的姿勢，
大部分情況下我作為架構師并不需要攬下“核心模塊”開發這種作業，畢竟我能調配的時間太零散了，效率難以保證，很多人在專注的情況下比我做的好很多，我只需要保持大局觀需要適度參與就可以了，
總的來說，架構師和程式員在某些方面上有點像產品經理和用戶的關系，大部分程式員并不會主動告訴你他們想要什么、哪里需要優化，甚至自己也不知道這些，想要做出好的產品，捷徑之一就是跟用戶做同樣的事情，
為什么別人的系統總是那么爛
很多程式員解決問題的能力很強，說要解決一個什么問題，下午就能寫出幾百行代碼把功能實作了，但是做出來的東西有種少考慮了什么東西的感覺，大部分程式都能實作功能，但是如果把“時間”這個也作為一個考慮的維度的話，就會意識到一個合格的專案需要考慮更多的東西：更通用的使用方式、易于理解的檔案、簡單而易于擴展的設計，等等，
很多公司應該都會有一些遺留系統，它們龐大、笨重、難用、幾乎無法維護，所有人都在抱怨這些系統，并且每天都在想方設法換掉那些遺留系統，但是一段時間過去之后，又會發現身邊的新人又開始吐槽當時替代遺留系統的那個系統了，
“大多數系統當初都很好使，功能當時夠用，擴展性看起來也可以，但是這些系統都是開發的人離職之后變壞的，”
成為架構師最困難的門檻是什么？
很多人自稱架構師的人跟你講一個架構時簡直滔滔不絕，各種技術名詞像是說相聲一樣從他嘴里說出來，三句話不離高并發大資料，但是稍微追問一下，就會發現很多基本概念的缺失，例如自稱精通高并發的人說不清楚他所謂的高并發系統的瓶頸在哪里，自稱精通架構設計的人說不明白他的系統怎么保證高可用，自稱超大資料量的系統實際上只有不到100萬條資料，等等，
架構師雖然聽起來很高大上，但本質上仍然是工程師，不是科學家，也不是忽悠人的江湖騙子，學習再多，也需要實踐落地，設計架構方案更多的是在做一些抽象和權衡：把復雜的需求抽象成簡單的模型，從功能、性能、可用性、研發成本等等方面規劃如何構建一個系統，這些內容需要更多的實踐練習，
如何更高效的學習？
大多數人每天能留給自己學習的時間有限，這個階段如何提升學習效率就成了要解決的重點，
說說自己提升學習效率的心得，其實非常簡單：體系化的學習，
在重復了幾次痛苦的學習-梳理程序后，再去看一些獨立的文章或者資料往往會事半功倍，因為能在體系內找到相對應的知識，甚至有時候一本書里一頁只需要看一句話，點破那層窗戶紙，就可以掌握新的知識，
跟很多人一樣，剛畢業時我覺得作為程式員，只要努力，加上少許天賦便可以獲得一些成績，
作業一段時間后，對自己和其他人的認識也越來越清晰，逐漸的發現程式員之間的差距或許比人和猴子之間的差距還大，接受這個事實這讓我郁悶了很久，
再過一段時間，發現自己已經能夠客觀的評價自己的能力，也意識到了距離并不是那么重要，只要想辦法跑的更快，就足夠了，
快速成為架構師的學習路線
以下是我從業多年總結出來的經驗，都是當前最主流的技術，技術太多，就只隨便截了兩張，也算是重點知識了，
最后提供免費的Java架構學習資料，學習技術內容包含有：Spring，Dubbo，MyBatis, RPC, 原始碼分析，高并發、高性能、分布式,性能優化，微服務 高級架構開發等等，
點擊：點這個！點這個！暗號：csdn,即可全部獲得，
還有Java核心知識點+全套架構師學習資料和視頻+一線大廠面試寶典+面試簡歷模板可以領取+阿里美團網易騰訊小米愛奇藝快手嗶哩嗶哩面試題+Spring原始碼合集+Java架構實戰電子書，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/132153.html
標籤：其他