工作了挺久，發(fā)現(xiàn)有個(gè)挺有意思的現(xiàn)象，從程序員、高級(jí)程序員，到現(xiàn)在掛著架構(gòu)師、專家之類的頭銜，伴隨著技術(shù)和能力的提高，想不明白的事情反而越來(lái)越多了。這些疑問(wèn)有些來(lái)自于跟小伙伴交流，有些是我的自問(wèn)自答，有些到現(xiàn)在也想不清楚，這篇文章就來(lái)寫一寫這些問(wèn)題。

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

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

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

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

說(shuō)說(shuō)自己提升學(xué)習(xí)效率的心得，其實(shí)非常簡(jiǎn)單：體系化的學(xué)習(xí)。

我曾經(jīng)很喜歡看一些博客或者是一些 “看起來(lái)” 比較通俗易懂的文章，每天在微博微信里刷到什么技術(shù)文章就 mark 下來(lái)，基本上幾分鐘就能讀完。可一段時(shí)間下來(lái)，雖然讀了不少東西，但是還是有種在原地打轉(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)系起來(lái)，比如說(shuō)后端服務(wù)的開發(fā)，簡(jiǎn)單梳理一下，就成了這樣：

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

你是怎么知道這些的？

工作中總是會(huì)遇到各種各樣的問(wèn)題，有幾次把問(wèn)題處理過(guò)程總結(jié)了一下，發(fā)了出來(lái)，之后就像滾雪球一樣，有越來(lái)越多的小伙伴來(lái)咨詢問(wèn)題，比如說(shuō)：

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

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

某次代碼有 bug，小伙伴跑來(lái)來(lái)問(wèn)我 git 怎么才能回滾代碼。

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

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

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

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

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

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

架構(gòu)師應(yīng)不應(yīng)該寫代碼？

似乎隔三差五就能看到一些關(guān)于架構(gòu)師應(yīng)不應(yīng)該寫代碼的文章。我是屬于寫代碼派，因?yàn)槲冶旧砭拖矚g寫代碼。但是，當(dāng)工作職責(zé)發(fā)生變化之后，如何保持寫代碼和其它工作之間的平衡就成了問(wèn)題。

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

但作為架構(gòu)師，參與寫代碼還是會(huì)有一些不大不小的收益。

一般來(lái)說(shuō)合格的程序員對(duì)于明確分配的任務(wù)會(huì)完成的很好，但是大部分情況下 “架構(gòu)” 這個(gè)詞意味著架構(gòu)師并不會(huì)涉及太多細(xì)節(jié)，架構(gòu)圖和代碼實(shí)現(xiàn)之間總還是有些距離，你無(wú)法保證所有人都會(huì)正確的理解你的設(shè)計(jì)，或者是程序員寫代碼時(shí)遇到障礙時(shí)會(huì)立刻想出足夠優(yōu)雅的解決方案。

之前寫過(guò)一篇關(guān)于爛代碼的文章 ，大部分爛代碼并不是架構(gòu)師的設(shè)計(jì)問(wèn)題，如果程序員沒能很好的理解設(shè)計(jì)或者是經(jīng)驗(yàn)不足，往往會(huì)做出一些非常匪夷所思的東西。比如我見過(guò)剛畢業(yè)的程序員為了 防止模塊耦合而將耦合的代碼又拷貝了一份，或者為了 “優(yōu)化性能” 而盡量把所有邏輯寫在一個(gè)函數(shù)里。

如果不能及時(shí)發(fā)現(xiàn)并改正這些問(wèn)題，那么這些地方就會(huì)變成 “正確的錯(cuò)誤代碼”，或者” 不是我寫的 “代碼，或者” 我靠我也看過(guò)那段代碼 “之類足以被掛上恥辱柱的玩意。這種問(wèn)題算是架構(gòu)師的責(zé)任嗎？作為一個(gè)視名聲如命的架構(gòu)師，我認(rèn)為是的。

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

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

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

實(shí)踐：開會(huì)是個(gè)技術(shù)活嗎？

我覺得應(yīng)該沒有人喜歡開會(huì)，身為一個(gè)程序員，沒有幾個(gè)人的志向是當(dāng)什么職場(chǎng)交際花。

但是會(huì)議邀請(qǐng)就這么一個(gè)個(gè)的跳了出來(lái)：開發(fā)需求要跟產(chǎn)品開會(huì)、項(xiàng)目方案要跟技術(shù)開會(huì)、新人轉(zhuǎn)正要去開評(píng)審會(huì)、別的公司來(lái)了幾個(gè)大牛正在開分享會(huì)、出 了故障要開總結(jié)會(huì)、小組有周會(huì)、部門有周會(huì)，大項(xiàng)目每周開兩次碰頭會(huì)不過(guò)分吧？小項(xiàng)目啟動(dòng)的時(shí)候開個(gè)會(huì)不過(guò)分吧？調(diào)試的時(shí)候發(fā)現(xiàn)有個(gè)坑大家趕緊討論討論 吧？

有時(shí)候參加的會(huì)議整場(chǎng)下來(lái)跟我毛關(guān)系都沒有，全程神游倆鐘頭，最后突然有人一拍桌子：” 還有問(wèn)題沒？好，散了！“

也有可能有個(gè)什么會(huì)沒叫你，過(guò)了倆禮拜突然收到封郵件催開發(fā)進(jìn)度，” 當(dāng)時(shí)那個(gè)會(huì)你沒參加，大家都說(shuō)應(yīng)該是你們做……你沒看會(huì)議紀(jì)要嗎？“

吐槽了這么多，但我還是認(rèn)為開會(huì)是個(gè)技術(shù)活，對(duì)于架構(gòu)師來(lái)說(shuō)尤其如此。

大多數(shù)技術(shù)人員開會(huì)并不是那種新聞里的工作匯報(bào)或者長(zhǎng)者們的會(huì)議，他們真的需要通過(guò)開會(huì)討論一個(gè)具體方案，或者解決什么具體問(wèn)題。可惜的是我參加過(guò) 很多會(huì)議，大多數(shù)的會(huì)議都是在毫無(wú)意義的交流中浪費(fèi)時(shí)間：幾方人坐在一個(gè)屋里互相說(shuō)一些對(duì)方理解不了的話，最后得出一個(gè)” 我們會(huì)后再捋一捋 “之類的結(jié)論。

這并不是會(huì)議才有的問(wèn)題，在程序員日常的溝通中，也有很多人并不懂得如何交流，比如偶爾會(huì)收到一些寫的非常認(rèn)真的郵件，打開之后是密密麻麻的一屏幕文字，但是從第一句開始就不知道他在說(shuō)什么，后面的東西連看的動(dòng)力都沒有了。

大多數(shù)時(shí)候，溝通的核心不是你說(shuō)了什么，而是你想要讓對(duì)方了解什么、讓他做什么。良好的溝通能在工作中顯著提升效率，但很多人忽略了這個(gè)事情。

想要恰到好處的進(jìn)行溝通是一件不那么輕松的事情，但是簡(jiǎn)單來(lái)說(shuō)有幾條原則：

確保各方對(duì)背景的理解一致，比如開會(huì)之前先簡(jiǎn)單通過(guò)郵件交流一下，對(duì)新加入會(huì)議的人花個(gè) 30 秒鐘做個(gè)前情提要，或者在討論過(guò)程中讓對(duì)方說(shuō)一下他的理解。

去掉對(duì)方不能 / 不需要理解的內(nèi)容，比如跟產(chǎn)品說(shuō) “這個(gè)隊(duì)列在高并發(fā)下因?yàn)殒i的實(shí)現(xiàn)有問(wèn)題導(dǎo)致 CPU 性能瓶頸” 不如改成 “我們發(fā)現(xiàn)了性能問(wèn)題，持續(xù) 10 分鐘了，10 萬(wàn)用戶收不到運(yùn)營(yíng)發(fā)的無(wú)節(jié)操?gòu)V告，大概 5 分鐘后擴(kuò)容解決”。

確保在對(duì)方失去注意力前盡快說(shuō)出重點(diǎn)，比如排查問(wèn)題的總結(jié)郵件，如果第一段是這樣：“某某框架內(nèi)部使用的是 xxx 技術(shù)，這個(gè)技術(shù)的架構(gòu)是這樣：blabla”，那么對(duì)方可能完全不知道你在講什么?？梢該Q成這樣：“我發(fā)現(xiàn)了某某框架的 bug，需要盡快升級(jí)，否則在 xxx 情況下有可能會(huì)出現(xiàn) yyy 問(wèn)題，具體排查過(guò)程如下：blabla”。

不要說(shuō)沒有意義的內(nèi)容浪費(fèi)其他人的時(shí)間，比如” 這需求做不了 “或者” 這里不可能出 bug “，沒有人想聽到這些廢話。

為什么別人的系統(tǒng)總是那么爛？

很多程序員解決問(wèn)題的能力很強(qiáng)，說(shuō)要解決一個(gè)什么問(wèn)題，下午就能寫出幾百行代碼把功能實(shí)現(xiàn)了。但是做出來(lái)的東西有種少考慮了什么東西的感覺，我花了挺久去想一個(gè)詞去形容 “這個(gè)東西”，最后想出了個(gè)勉強(qiáng)可以表達(dá)的詞：程序的生命力。

大部分程序都能實(shí)現(xiàn)功能，但是如果把 “時(shí)間” 這個(gè)也作為一個(gè)考慮的維度的話，就會(huì)意識(shí)到一個(gè)合格的項(xiàng)目需要考慮更多的東西：更通用的使用方式、易于理解的文檔、簡(jiǎn)單而易于擴(kuò)展的設(shè)計(jì)，等等。而想要?dú)У舫绦虻纳σ埠芎?jiǎn)單：做的更復(fù)雜，更定制化，讓更少的人參與。

我跟很多程序員提過(guò)程序的生命力，比如說(shuō)要讓自己寫的工具的操作方式跟其它 Linux 命令類似，或者要用一些更容易理解但不是性能最優(yōu)的設(shè)計(jì)方式，又或者要他去參考現(xiàn)在業(yè)界主流的做法，很多人認(rèn)為提這種需求的意義不大，我覺得這里還是舉個(gè)例子吧。

很多公司應(yīng)該都會(huì)有一些遺留系統(tǒng)，它們龐大、笨重、難用、幾乎無(wú)法維護(hù)，所有人都在抱怨這些系統(tǒng)，并且每天都在想方設(shè)法換掉那些遺留系統(tǒng)。但是一段時(shí)間過(guò)去之后，又會(huì)發(fā)現(xiàn)身邊的新人又開始吐槽當(dāng)時(shí)替代遺留系統(tǒng)的那個(gè)系統(tǒng)了。

“大多數(shù)系統(tǒng)當(dāng)初都很好使，功能當(dāng)時(shí)夠用，擴(kuò)展性看起來(lái)也可以，但是這些系統(tǒng)都是開發(fā)的人離職之后變壞的。”

還有更好的辦法嗎？

成為技術(shù)專家之后的工作可以說(shuō)是痛并快樂(lè)著，會(huì)有很多人找你咨詢問(wèn)題，另一方面，會(huì)有太多人找你咨詢問(wèn)題。

甚至有一段時(shí)間我每天的工作就是解答問(wèn)題，小到工具使用中到疑難 bug，大到架構(gòu)設(shè)計(jì)，從早上到晚上基本都是在給各種各樣的小伙伴提供咨詢服務(wù)。

我很快發(fā)現(xiàn)有些地方不對(duì)頭：有些問(wèn)題實(shí)在是太簡(jiǎn)單了，以至于我甚至都不用思考就可以給出答案，為什么會(huì)有這種問(wèn)題？

后來(lái)我在每次回答之前先問(wèn)一句：

“你還有更好的辦法嗎？”

一小部分人立刻能給出優(yōu)化后的版本，甚至我連續(xù)問(wèn)幾次之后，他能給出好幾個(gè)優(yōu)化后的版本；另小一部分人會(huì)斬釘截鐵的說(shuō)優(yōu)化不了了，就這樣了。但是大部分人會(huì)猶猶豫豫的說(shuō)出一些完全不著調(diào)的回答。

后來(lái)我改成在每次回答之前先問(wèn)兩句：

“你要解決什么問(wèn)題？”

“還有更好的辦法嗎？”

效果好了很多，很多小伙伴發(fā)現(xiàn)要解決的問(wèn)題并不復(fù)雜，只是做法跑偏了。

再后來(lái)我改成了在每次回答之前先問(wèn)三句：

“他們要你解決什么問(wèn)題？”

“你解決的是什么問(wèn)題？“

” 還有更好的辦法嗎？“

現(xiàn)在第三句已經(jīng)很少問(wèn)到了。

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

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

我最近幾年面試的人挺多，發(fā)現(xiàn)一個(gè)有意思的現(xiàn)象：很多人自稱架構(gòu)師的人跟你講一個(gè)架構(gòu)時(shí)簡(jiǎn)直滔滔不絕，各種技術(shù)名詞像是說(shuō)相聲一樣從他嘴里說(shuō)出來(lái)， 三句話不離高并發(fā)大數(shù)據(jù)，但是稍微追問(wèn)一下，就會(huì)發(fā)現(xiàn)很多基本概念的缺失，例如自稱精通高并發(fā)的人說(shuō)不清楚他所謂的高并發(fā)系統(tǒng)的瓶頸在哪里，自稱精通架構(gòu) 設(shè)計(jì)的人說(shuō)不明白他的系統(tǒng)怎么保證高可用，自稱超大數(shù)據(jù)量的系統(tǒng)實(shí)際上只有不到 100 萬(wàn)條數(shù)據(jù)，等等。

架構(gòu)師雖然聽起來(lái)很高大上，但本質(zhì)上仍然是工程師，不是科學(xué)家，也不是忽悠人的江湖騙子。學(xué)習(xí)再多，也需要實(shí)踐落地。設(shè)計(jì)架構(gòu)方案更多的是在做一些 抽象和權(quán)衡：把復(fù)雜的需求抽象成簡(jiǎn)單的模型，從功能、性能、可用性、研發(fā)成本等等方面規(guī)劃如何構(gòu)建一個(gè)系統(tǒng)，這些內(nèi)容需要更多的實(shí)踐練習(xí)。

很多人沒有工作在類似微博平臺(tái)這種天天需要接觸架構(gòu)設(shè)計(jì)的地方，而很多公司沒有架構(gòu)方面的工作可供他們練級(jí)，于是就想辦法從理論上下功夫，這類人的特征非常明顯：在信息不足，甚至不了解實(shí)際場(chǎng)景的情況下就開始做架構(gòu)設(shè)計(jì)，這種所謂的架構(gòu)往往理解比較膚淺，經(jīng)不住推敲。

每年招人之后我們都會(huì)做一些針對(duì)新人的架構(gòu)方面的培訓(xùn)，課程材料基本上包括了高可用架構(gòu)相關(guān)的主要方面，但是學(xué)完這些材料之后就能成為獨(dú)當(dāng)一面的架 構(gòu)師了嗎？并沒有。相反，這僅僅是開始，新人真正做了幾個(gè)并發(fā)量上萬(wàn)的系統(tǒng)之后才算是正式入門：面對(duì)壓力時(shí)才會(huì)懂得權(quán)衡，走過(guò)彎路之后才會(huì)尋找捷徑。

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

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

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

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

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