工作了挺久，發(fā)現(xiàn)有個(gè)挺有意思的現(xiàn)象，從程序員、高級(jí)程序員，到現(xiàn)在掛著架構(gòu)師、專家之類的頭銜，伴隨著技術(shù)和能力的提高，想不明白的事情反而越來越多了。

　　這些疑問有些來自于跟小伙伴的交流，有些是我的自問自答，有些到現(xiàn)在也想不清楚，這篇文章就來寫一寫這些問題。

　　如何更高效的學(xué)習(xí)？

　　很多新人程序員一開始在學(xué)習(xí)上找不到方向，但我想在渡過了一段時(shí)間的新手期之后，這類問題大多都會(huì)變得不再那么明顯，工作的方向也會(huì)逐漸變得清晰起來。

　　但是沒過多久，能了解到的資料就開始超過每天學(xué)習(xí)的能力，像是買了沒看的書、收藏沒讀的貼、Mark了之后再也沒有關(guān)注過的文章越積越多，更別提每天面對各種技術(shù)分享或者微博里的新鮮玩意了

　　大多數(shù)人每天能留給自己學(xué)習(xí)的時(shí)間有限，這個(gè)階段如何提升學(xué)習(xí)效率就成了要解決的重點(diǎn)。

　　說說自己提升學(xué)習(xí)效率的心得，非常簡單：體系化的學(xué)習(xí)。

　　我曾經(jīng)很喜歡看一些博客或者是一些“看起來”比較通俗易懂的文章，每天在微博微信里刷到什么技術(shù)文章就Mark下來，基本上幾分鐘就能讀完。

　　可一段時(shí)間下來，雖然讀了不少東西，但是還是有種在原地打轉(zhuǎn)的狀態(tài)，并沒有感受到有什么實(shí)際的提高。

　　最后實(shí)在忍不住，抱著厚書硬啃了一遍，突然有種豁然開朗的感覺：讀書時(shí)自己學(xué)到的是一張完整的知識(shí)網(wǎng)絡(luò)，每個(gè)知識(shí)點(diǎn)和其它內(nèi)容相互聯(lián)系和區(qū)別。這種全方位的理解比起一篇篇獨(dú)立的文章，不知要高到哪里去了。

　　而讀了一段時(shí)間書之后，漸漸原本不在一個(gè)體系之內(nèi)的知識(shí)也會(huì)慢慢聯(lián)系起來，比如說后端服務(wù)的開發(fā)，簡單梳理一下，就成了這樣：

　　在重復(fù)了幾次痛苦的學(xué)習(xí)-梳理過程后，再去看一些獨(dú)立的文章或者資料往往會(huì)事半功倍，因?yàn)槟茉隗w系內(nèi)找到相對應(yīng)的知識(shí)，甚至有時(shí)候一本書里一頁只需要看一句話，點(diǎn)破那層窗戶紙，就可以掌握新的知識(shí)。

　　你是怎么知道這些的？

　　工作中總是會(huì)遇到各種各樣的問題，有幾次把問題處理過程總結(jié)了一下，發(fā)了出來，之后就像滾雪球一樣，有越來越多的小伙伴來咨詢問題。

　　比如說：前一陣幫忙排查一個(gè)性能問題，系統(tǒng)壓力稍微一大就會(huì)頻繁FullGC，壓力降低之后又恢復(fù)了。

　　某個(gè)小伙伴接入代碼質(zhì)量檢查系統(tǒng)之后發(fā)現(xiàn)每次構(gòu)建會(huì)報(bào)一個(gè)莫名其妙的錯(cuò)誤，打不了包。

　　某次代碼有Bug，小伙伴跑來來問我git怎么才能回滾代碼。

　　每次查完這種問題的時(shí)候，一些剛畢業(yè)沒多久小伙伴們就會(huì)用一種崇拜的眼神看著我，然后大多會(huì)問：“你是怎么知道這些的?”

　　實(shí)際上，雖然我一直在不斷的學(xué)習(xí)，但是面對工作中無窮無盡的新問題，大部分問題還是會(huì)命中我沒有掌握的那部分區(qū)域。每次有人問到我不了解的知識(shí)時(shí)我都會(huì)非常開心：還有什么比帶著問題學(xué)習(xí)更有效率的學(xué)習(xí)方法呢?

　　而且幸運(yùn)的是，在建立了自己的知識(shí)體系的基礎(chǔ)上，學(xué)習(xí)新的知識(shí)通常都能很快的上手，解決一個(gè)問題往往只需要多了解一個(gè)知識(shí)點(diǎn)而已。

　　舉個(gè)例子，頻繁FullGC的問題，以前查過很多次GC的問題，大多數(shù)是Java程序或JVM內(nèi)存泄露問題，而這次內(nèi)存沒有泄露，GC吞吐量也正常，那么我只需要查一下如何查看一段時(shí)間內(nèi)創(chuàng)建的最多的對象的方法就可以了。

　　回到剛才的問題，小伙伴們問我：“你是怎么學(xué)到這些的知識(shí)的?”

　　答案是：在你問我問題之后現(xiàn)學(xué)的。

　　似乎隔三差五就能看到一些關(guān)于架構(gòu)師應(yīng)不應(yīng)該寫代碼的文章。我是屬于寫代碼派，因?yàn)槲冶旧砭拖矚g寫代碼。

　　但是，當(dāng)工作職責(zé)發(fā)生變化之后，如何保持寫代碼和其它工作之間的平衡就成了問題。

　　從個(gè)體效率上來看，我自己親自寫代碼，和很多人相比沒有什么絕對優(yōu)勢，甚至有些人碼代碼的速度比我還快一些。

　　但作為架構(gòu)師，參與寫代碼還是會(huì)有一些不大不小的收益。一般來說合格的程序員對于明確分配的任務(wù)會(huì)完成的很好，但是大部分情況下“架構(gòu)”這個(gè)詞意味著架構(gòu)師并不會(huì)涉及太多細(xì)節(jié)。

　　架構(gòu)圖和代碼實(shí)現(xiàn)之間總還是有些距離，你無法保證所有人都會(huì)正確的理解你的設(shè)計(jì)，或者是程序員寫代碼時(shí)遇到障礙時(shí)會(huì)立刻想出足夠優(yōu)雅的解決方案。

　　之前寫過一篇關(guān)于爛代碼的文章，大部分爛代碼并不是架構(gòu)師的設(shè)計(jì)問題，如果程序員沒能很好的理解設(shè)計(jì)或者是經(jīng)驗(yàn)不足，往往會(huì)做出一些非常匪夷所思的東西。

　　比如我見過剛畢業(yè)的程序員為了防止模塊耦合而將耦合的代碼又拷貝了一份，或者為了“優(yōu)化性能”而盡量把所有邏輯寫在一個(gè)函數(shù)里。

　　如果不能及時(shí)發(fā)現(xiàn)并改正這些問題，那么這些地方就會(huì)變成“正確的錯(cuò)誤代碼”，或者“不是我寫的”代碼，或者“我靠我也看過那段代碼”之類足以被掛上恥辱柱的玩意。

　　這種問題算是架構(gòu)師的責(zé)任嗎？作為一個(gè)視名聲如命的架構(gòu)師，我認(rèn)為是的。

　　在我看來，寫代碼的架構(gòu)師更像是在做后勤保障的工作：在代碼中第一時(shí)間發(fā)現(xiàn)可能存在的問題，向其他人提出警告；或是給予其他人改進(jìn)的意見，必要的時(shí)候給其他人演示一下正確的姿勢。

　　大部分情況下我作為架構(gòu)師并不需要攬下“核心模塊”開發(fā)這種工作，畢竟我能調(diào)配的時(shí)間太零散了，效率難以保證，很多人在專注的情況下比我做的好很多，我只需要保持大局觀，需要時(shí)適度參與就可以了。

　　總的來說，架構(gòu)師和程序員在某些方面上有點(diǎn)像產(chǎn)品經(jīng)理和用戶的關(guān)系，大部分程序員并不會(huì)主動(dòng)告訴你他們想要什么、哪里需要優(yōu)化，甚至自己也不知道這些。想要做出好的產(chǎn)品，捷徑之一就是跟用戶做同樣的事情。

　　成為架構(gòu)師最困難的門檻是什么？

　　跟一些程序員交流的過程中，有不少人問我要怎么成為一名牛逼的架構(gòu)師。

　　我最近幾年面試的人挺多，發(fā)現(xiàn)一個(gè)有意思的現(xiàn)象：很多自稱架構(gòu)師的人跟你講一個(gè)架構(gòu)時(shí)簡直滔滔不絕，各種技術(shù)名詞像是說相聲一樣從他嘴里說出來，三句話不離高并發(fā)、大數(shù)據(jù)。

　　但是稍微追問一下，就會(huì)發(fā)現(xiàn)很多基本概念的缺失，例如自稱精通高并發(fā)的人說不清楚他所謂的高并發(fā)系統(tǒng)的瓶頸在哪里，自稱精通架構(gòu)設(shè)計(jì)的人說不明白他的系統(tǒng)怎么保證高可用，自稱超大數(shù)據(jù)量的系統(tǒng)實(shí)際上只有不到100萬條數(shù)據(jù)，等等。

　　架構(gòu)師雖然聽起來很高大上，但本質(zhì)上仍然是工程師，不是科學(xué)家，也不是忽悠人的江湖騙子。學(xué)習(xí)再多，也需要實(shí)踐落地。

　　設(shè)計(jì)架構(gòu)方案更多的是在做一些抽象和權(quán)衡：把復(fù)雜的需求抽象成簡單的模型，從功能、性能、可用性、研發(fā)成本等等方面規(guī)劃如何構(gòu)建一個(gè)系統(tǒng)，這些內(nèi)容需要更多的實(shí)踐練習(xí)。

　　很多人沒有工作在類似微博平臺(tái)這種天天需要接觸架構(gòu)設(shè)計(jì)的地方，而很多公司沒有架構(gòu)方面的工作可供他們練級(jí)，于是就想辦法從理論上下功夫。

　　這類人的特征非常明顯：在信息不足，甚至不了解實(shí)際場景的情況下就開始做架構(gòu)設(shè)計(jì)，這種所謂的架構(gòu)往往理解比較膚淺，經(jīng)不住推敲。

　　每年招人之后我們都會(huì)做一些針對新人的架構(gòu)方面的培訓(xùn)，課程材料基本上包括了高可用架構(gòu)相關(guān)的主要方面，但是學(xué)完這些材料之后就能成為獨(dú)當(dāng)一面的架構(gòu)師了嗎？并沒有。

　　相反，這僅僅是開始，新人真正做了幾個(gè)并發(fā)量上萬的系統(tǒng)之后才算是正式入門：面對壓力時(shí)才會(huì)懂得權(quán)衡，走過彎路之后才會(huì)尋找捷徑。

　　所以我認(rèn)為在架構(gòu)師(和其它很多)的工作中最重要的部分是實(shí)踐，夸夸其談很容易，與其拽一些技術(shù)名詞，不如把你正在做的系統(tǒng)真正的做好。

　　我和大牛之間有多少距離？

　　技術(shù)上的差別可以補(bǔ)上可以看看如下架構(gòu)圖：經(jīng)驗(yàn)上的差別那就只能看自己的沉淀了。

　　跟很多人一樣，剛畢業(yè)時(shí)我覺得作為程序員，只要努力，加上少許天賦便可以獲得一些成績。

　　工作一段時(shí)間后，對自己和其他人的認(rèn)識(shí)也越來越清晰，逐漸的發(fā)現(xiàn)程序員之間的差距或許比人和猴子之間的差距還大，接受這個(gè)事實(shí)讓我郁悶了很久。

　　再過一段時(shí)間，發(fā)現(xiàn)自己已經(jīng)能夠客觀的評(píng)價(jià)自己的能力，也意識(shí)到了距離并不是那么重要，只要想辦法跑的更快，就足夠了。

　　以上就是動(dòng)力Java培訓(xùn)機(jī)構(gòu)小編介紹的“從菜鳥到Java架構(gòu)師你還差多少距離”的內(nèi)容，希望對大家有幫助，如有疑問，請?jiān)诰€咨詢，有專業(yè)老師隨時(shí)為你服務(wù)。