- 一個(gè)系統架構師的成長(cháng)之路 推薦度：
- 相關(guān)推薦
架構師的成長(cháng)之路
從程序員、高級程序員，再到架構師，這是所有架構師的必經(jīng)之路，下面為大家分享一位架構師的成長(cháng)之路，希望對大家有所幫助！
如何更高效地學(xué)習?
很多新人程序員一開(kāi)始在學(xué)習上找不到方向，但我想在渡過(guò)了一段時(shí)間的新手期之后這類(lèi)問(wèn)題大多都會(huì )變得不再那么明顯，工作的方向也會(huì )逐漸變得清晰起來(lái)。
但是沒(méi)過(guò)多久，能了解到的資料就開(kāi)始超過(guò)每天學(xué)習的能力，像是買(mǎi)了沒(méi)看的書(shū)、收藏沒(méi)讀的貼、mark了之后再也沒(méi)有關(guān)注過(guò)的文章越積越多，更別提每天面對各種技術(shù)分享或者微博里的新鮮玩意了。
大多數人每天能留給自己學(xué)習的時(shí)間有限，這個(gè)階段如何提升學(xué)習效率就成了要解決的重點(diǎn)。
說(shuō)說(shuō)自己提升學(xué)習效率的心得，其實(shí)非常簡(jiǎn)單：體系化的學(xué)習。
我曾經(jīng)很喜歡看一些博客或者是一些“看起來(lái)”比較通俗易懂的文章，每天在微博微信里刷到什么技術(shù)文章就mark下來(lái)，基本上幾分鐘就能讀完�？梢欢螘r(shí)間下來(lái)，雖然讀了不少東西，但是還是有種在原地打轉的狀態(tài)，并沒(méi)有感受到有什么實(shí)際的提高。
最后實(shí)在忍不住，抱著(zhù)厚書(shū)硬啃了一遍，突然有種豁然開(kāi)朗的感覺(jué)：讀書(shū)時(shí)自己學(xué)到的是一張完整的知識網(wǎng)絡(luò )，每個(gè)知識點(diǎn)和其它內容相互聯(lián)系和區別。這種全方位的理解比起一篇篇獨立的文章，不知要高到哪里去了。
而讀了一段時(shí)間書(shū)之后，漸漸原本不在一個(gè)體系之內的知識也會(huì )慢慢聯(lián)系起來(lái)，比如說(shuō)后端服務(wù)的開(kāi)發(fā)，簡(jiǎn)單梳理一下，就成了這樣：
在重復了幾次痛苦的學(xué)習梳理過(guò)程后，再去看一些獨立的文章或者資料往往會(huì )事半功倍，因為能在體系內找到相對應的知識，甚至有時(shí)候一本書(shū)里一頁(yè)只需要看一句話(huà)，點(diǎn)破那層窗戶(hù)紙，就可以掌握新的知識。
你是怎么知道這些的?
工作中總是會(huì )遇到各種各樣的問(wèn)題，有幾次把問(wèn)題處理過(guò)程總結了一下，發(fā)了出來(lái)，之后就像滾雪球一樣，有越來(lái)越多的小伙伴來(lái)咨詢(xún)問(wèn)題，比如說(shuō)：
前一陣幫忙排查一個(gè)性能問(wèn)題，系統壓力稍微一大就會(huì )頻繁Full GC，壓力降低之后又恢復了。
某個(gè)小伙伴接入代碼質(zhì)量檢查系統之后發(fā)現每次構建會(huì )報一個(gè)莫名其妙的錯誤，打不了包。
某次代碼有bug，小伙伴跑來(lái)來(lái)問(wèn)我git怎么才能回滾代碼。
每次查完這種問(wèn)題的時(shí)候，一些剛畢業(yè)沒(méi)多久小伙伴們就會(huì )用一種崇拜的眼神看著(zhù)我，然后大多會(huì )問(wèn)：“你是怎么知道這些的?”
實(shí)際上，雖然我一直在不斷的學(xué)習，但是面對工作中無(wú)窮無(wú)盡的新問(wèn)題，大部分問(wèn)題還是會(huì )命中我沒(méi)有掌握的那部分區域。每次有人問(wèn)到我不了解的知識時(shí)我都會(huì )非常開(kāi)心：還有什么比帶著(zhù)問(wèn)題學(xué)習更有效率的學(xué)習方法呢?
而且幸運的是，在建立了自己的知識體系的基礎上，學(xué)習新的知識通常都能很快的上手，解決一個(gè)問(wèn)題往往只需要多了解一個(gè)知識點(diǎn)而已。
舉個(gè)例子，頻繁Full GC的問(wèn)題，以前查過(guò)很多次GC的問(wèn)題，大多數是Java程序或JVM內存泄露問(wèn)題，而這次內存沒(méi)有泄露，GC吞吐量也正常，那么我只需要查一下如何查看一段時(shí)間內創(chuàng )建的最多的對象的方法就可以了。
回到剛才的問(wèn)題，小伙伴們問(wèn)我：“你是怎么學(xué)到這些的知識的?”
答案是：在你問(wèn)我問(wèn)題之后現學(xué)的。
架構師應不應該寫(xiě)代碼?
似乎隔三差五就能看到一些關(guān)于架構師應不應該寫(xiě)代碼的文章。我是屬于寫(xiě)代碼派，因為我本身就喜歡寫(xiě)代碼。但是，當工作職責發(fā)生變化之后，如何保持寫(xiě)代碼和其它工作之間的平衡就成了問(wèn)題。
從個(gè)體效率上來(lái)看，我自己親自寫(xiě)代碼，和很多人相比沒(méi)有什么絕對優(yōu)勢，甚至有些人碼代碼的速度比我還快一些。
但作為架構師，參與寫(xiě)代碼還是會(huì )有一些不大不小的收益。
一般來(lái)說(shuō)合格的程序員對于明確分配的任務(wù)會(huì )完成的很好，但是大部分情況下“架構”這個(gè)詞意味著(zhù)架構師并不會(huì )涉及太多細節，架構圖和代碼實(shí)現之間總還是有些距離，你無(wú)法保證所有人都會(huì )正確的理解你的設計，或者是程序員寫(xiě)代碼時(shí)遇到障礙時(shí)會(huì )立刻想出足夠優(yōu)雅的解決方案。
之前寫(xiě)過(guò)一篇關(guān)于爛代碼的文章 ，大部分爛代碼并不是架構師的設計問(wèn)題，如果程序員沒(méi)能很好的理解設計或者是經(jīng)驗不足，往往會(huì )做出一些非常匪夷所思的東西。比如我見(jiàn)過(guò)剛畢業(yè)的程序員為了防止模塊耦合而將耦合的代碼又拷貝了一份，或者為了“優(yōu)化性能”而盡量把所有邏輯寫(xiě)在一個(gè)函數里。
如果不能及時(shí)發(fā)現并改正這些問(wèn)題，那么這些地方就會(huì )變成“正確的錯誤代碼”，或者”不是我寫(xiě)的“代碼，或者”我靠我也看過(guò)那段代碼“之類(lèi)足以被掛上恥辱柱的玩意。這種問(wèn)題算是架構師的責任嗎?作為一個(gè)視名聲如命的架構師，我認為是的。
在我看來(lái)，寫(xiě)代碼的架構師更像是在做后勤保障的工作：在代碼中第一時(shí)間發(fā)現可能存在的問(wèn)題，向其他人提出警告，或是給予其他人改進(jìn)的意見(jiàn)，必要的時(shí)候或是給其他人演示一下正確的姿勢。
大部分情況下我作為架構師并不需要攬下“核心模塊”開(kāi)發(fā)這種工作，畢竟我能調配的時(shí)間太零散了，效率難以保證，很多人在專(zhuān)注的情況下比我做的好很多，我只需要保持大局觀(guān)需要適度參與就可以了。
總的來(lái)說(shuō)，架構師和程序員在某些方面上有點(diǎn)像產(chǎn)品經(jīng)理和用戶(hù)的關(guān)系，大部分程序員并不會(huì )主動(dòng)告訴你他們想要什么、哪里需要優(yōu)化，甚至自己也不知道這些。想要做出好的產(chǎn)品，捷徑之一就是跟用戶(hù)做同樣的事情。
實(shí)踐：開(kāi)會(huì )是個(gè)技術(shù)活嗎?
我覺(jué)得應該沒(méi)有人喜歡開(kāi)會(huì )，身為一個(gè)程序員，沒(méi)有幾個(gè)人的志向是當什么職場(chǎng)交際花。
但是會(huì )議邀請就這么一個(gè)個(gè)的跳了出來(lái)：開(kāi)發(fā)需求要跟產(chǎn)品開(kāi)會(huì )、項目方案要跟技術(shù)開(kāi)會(huì )、新人轉正要去開(kāi)評審會(huì )、別的公司來(lái)了幾個(gè)大牛正在開(kāi)分享會(huì )、出了故障要開(kāi)總結會(huì )、小組有周會(huì )、部門(mén)有周會(huì )，大項目每周開(kāi)兩次碰頭會(huì )不過(guò)分吧?小項目啟動(dòng)的時(shí)候開(kāi)個(gè)會(huì )不過(guò)分吧?調試的時(shí)候發(fā)現有個(gè)坑大家趕緊討論討論吧?
有時(shí)候參加的會(huì )議整場(chǎng)下來(lái)跟我毛關(guān)系都沒(méi)有，全程神游倆鐘頭，最后突然有人一拍桌子：”還有問(wèn)題沒(méi)?好，散了!“
也有可能有個(gè)什么會(huì )沒(méi)叫你，過(guò)了倆禮拜突然收到封郵件催開(kāi)發(fā)進(jìn)度，”當時(shí)那個(gè)會(huì )你沒(méi)參加，大家都說(shuō)應該是你們做……你沒(méi)看會(huì )議紀要嗎?“
吐槽了這么多，但我還是認為開(kāi)會(huì )是個(gè)技術(shù)活，對于架構師來(lái)說(shuō)尤其如此。
大多數技術(shù)人員開(kāi)會(huì )并不是那種新聞里的工作匯報或者長(cháng)者們的會(huì )議，他們真的需要通過(guò)開(kāi)會(huì )討論一個(gè)具體方案，或者解決什么具體問(wèn)題�？上У氖俏覅⒓舆^(guò)很多會(huì )議，大多數的會(huì )議都是在毫無(wú)意義的交流中浪費時(shí)間：幾方人坐在一個(gè)屋里互相說(shuō)一些對方理解不了的話(huà)，最后得出一個(gè)”我們會(huì )后再捋一捋“之類(lèi)的結論。
這并不是會(huì )議才有的問(wèn)題，在程序員日常的溝通中，也有很多人并不懂得如何交流，比如偶爾會(huì )收到一些寫(xiě)的非常認真的郵件，打開(kāi)之后是密密麻麻的一屏幕文字，但是從第一句開(kāi)始就不知道他在說(shuō)什么，后面的東西連看的動(dòng)力都沒(méi)有了。
大多數時(shí)候，溝通的核心不是你說(shuō)了什么，而是你想要讓對方了解什么、讓他做什么。良好的溝通能在工作中顯著(zhù)提升效率，但很多人忽略了這個(gè)事情。
想要恰到好處的進(jìn)行溝通是一件不那么輕松的事情，但是簡(jiǎn)單來(lái)說(shuō)有幾條原則：
確保各方對背景的理解一致，比如開(kāi)會(huì )之前先簡(jiǎn)單通過(guò)郵件交流一下，對新加入會(huì )議的人花個(gè)30秒鐘做個(gè)前情提要，或者在討論過(guò)程中讓對方說(shuō)一下他的理解。
去掉對方不能/不需要理解的內容，比如跟產(chǎn)品說(shuō)“這個(gè)隊列在高并發(fā)下因為鎖的實(shí)現有問(wèn)題導致CPU性能瓶頸”不如改成“我們發(fā)現了性能問(wèn)題，持續10分鐘了，10萬(wàn)用戶(hù)收不到運營(yíng)發(fā)的無(wú)節操廣告，大概5分鐘后擴容解決”。
確保在對方失去注意力前盡快說(shuō)出重點(diǎn)，比如排查問(wèn)題的總結郵件，如果第一段是這樣：“某某框架內部使用的是xxx技術(shù)，這個(gè)技術(shù)的架構是這樣：blabla”，那么對方可能完全不知道你在講什么�？梢該Q成這樣：“我發(fā)現了某某框架的bug，需要盡快升級，否則在xxx情況下有可能會(huì )出現yyy問(wèn)題，具體排查過(guò)程如下：blabla”。
不要說(shuō)沒(méi)有意義的內容浪費其他人的時(shí)間，比如”這需求做不了“或者”這里不可能出bug“，沒(méi)有人想聽(tīng)到這些廢話(huà)。
為什么別人的系統總是那么爛?
很多程序員解決問(wèn)題的能力很強，說(shuō)要解決一個(gè)什么問(wèn)題，下午就能寫(xiě)出幾百行代碼把功能實(shí)現了。但是做出來(lái)的東西有種少考慮了什么東西的感覺(jué)，我花了挺久去想一個(gè)詞去形容“這個(gè)東西”，最后想出了個(gè)勉強可以表達的詞：程序的生命力。
大部分程序都能實(shí)現功能，但是如果把“時(shí)間”這個(gè)也作為一個(gè)考慮的維度的話(huà)，就會(huì )意識到一個(gè)合格的項目需要考慮更多的東西：更通用的使用方式、易于理解的文檔、簡(jiǎn)單而易于擴展的設計，等等。而想要毀掉程序的生命力也很簡(jiǎn)單：做的更復雜，更定制化，讓更少的人參與。
我跟很多程序員提過(guò)程序的生命力，比如說(shuō)要讓自己寫(xiě)的工具的操作方式跟其它Linux命令類(lèi)似，或者要用一些更容易理解但不是性能最優(yōu)的設計方式，又或者要他去參考現在業(yè)界主流的做法，很多人認為提這種需求的意義不大，我覺(jué)得這里還是舉個(gè)例子吧。
很多公司應該都會(huì )有一些遺留系統，它們龐大、笨重、難用、幾乎無(wú)法維護，所有人都在抱怨這些系統，并且每天都在想方設法換掉那些遺留系統。但是一段時(shí)間過(guò)去之后，又會(huì )發(fā)現身邊的新人又開(kāi)始吐槽當時(shí)替代遺留系統的那個(gè)系統了。
“大多數系統當初都很好使，功能當時(shí)夠用，擴展性看起來(lái)也可以，但是這些系統都是開(kāi)發(fā)的人離職之后變壞的�！�
還有更好的辦法嗎?
成為技術(shù)專(zhuān)家之后的工作可以說(shuō)是痛并快樂(lè )著(zhù)，會(huì )有很多人找你咨詢(xún)問(wèn)題，另一方面，會(huì )有太多人找你咨詢(xún)問(wèn)題。
甚至有一段時(shí)間我每天的工作就是解答問(wèn)題，小到工具使用中到疑難bug，大到架構設計，從早上到晚上基本都是在給各種各樣的小伙伴提供咨詢(xún)服務(wù)。
我很快發(fā)現有些地方不對頭：有些問(wèn)題實(shí)在是太簡(jiǎn)單了，以至于我甚至都不用思考就可以給出答案，為什么會(huì )有這種問(wèn)題?
后來(lái)我在每次回答之前先問(wèn)一句：
“你還有更好的辦法嗎?”
一小部分人立刻能給出優(yōu)化后的版本，甚至我連續問(wèn)幾次之后，他能給出好幾個(gè)優(yōu)化后的版本;另小一部分人會(huì )斬釘截鐵的說(shuō)優(yōu)化不了了，就這樣了。但是大部分人會(huì )猶猶豫豫的說(shuō)出一些完全不著(zhù)調的回答。
后來(lái)我改成在每次回答之前先問(wèn)兩句：
“你要解決什么問(wèn)題?”
“還有更好的辦法嗎?”
效果好了很多，很多小伙伴發(fā)現要解決的問(wèn)題并不復雜，只是做法跑偏了。
再后來(lái)我改成了在每次回答之前先問(wèn)三句：
“他們要你解決什么問(wèn)題?”
“你解決的是什么問(wèn)題?“
”還有更好的辦法嗎?“
現在第三句已經(jīng)很少問(wèn)到了。
成為架構師最困難的門(mén)檻是?
跟一些程序員交流的過(guò)程中，有不少人問(wèn)我要怎么成為一名牛逼的架構師。
我最近幾年面試的人挺多，發(fā)現一個(gè)有意思的現象：很多人自稱(chēng)架構師的人跟你講一個(gè)架構時(shí)簡(jiǎn)直滔滔不絕，各種技術(shù)名詞像是說(shuō)相聲一樣從他嘴里說(shuō)出來(lái)，三句話(huà)不離高并發(fā)大數據，但是稍微追問(wèn)一下，就會(huì )發(fā)現很多基本概念的缺失。
例如自稱(chēng)精通高并發(fā)的人說(shuō)不清楚他所謂的高并發(fā)系統的瓶頸在哪里，自稱(chēng)精通架構設計的人說(shuō)不明白他的系統怎么保證高可用，自稱(chēng)超大數據量的系統實(shí)際上只有不到100萬(wàn)條數據，等等。
架構師雖然聽(tīng)起來(lái)很高大上，但本質(zhì)上仍然是工程師，不是科學(xué)家，也不是忽悠人的江湖騙子。學(xué)習再多，也需要實(shí)踐落地。設計架構方案更多的是在做一些抽象和權衡：把復雜的需求抽象成簡(jiǎn)單的模型，從功能、性能、可用性、研發(fā)成本等等方面規劃如何構建一個(gè)系統，這些內容需要更多的實(shí)踐練習。
很多人沒(méi)有工作在類(lèi)似微博平臺這種天天需要接觸架構設計的地方，而很多公司沒(méi)有架構方面的工作可供他們練級，于是就想辦法從理論上下功夫，這類(lèi)人的特征非常明顯：在信息不足，甚至不了解實(shí)際場(chǎng)景的情況下就開(kāi)始做架構設計，這種所謂的架構往往理解比較膚淺，經(jīng)不住推敲。
每年招人之后我們都會(huì )做一些針對新人的架構方面的培訓，課程材料基本上包括了高可用架構相關(guān)的主要方面，但是學(xué)完這些材料之后就能成為獨當一面的架構師了嗎?并沒(méi)有。相反，這僅僅是開(kāi)始，新人真正做了幾個(gè)并發(fā)量上萬(wàn)的系統之后才算是正式入門(mén)：面對壓力時(shí)才會(huì )懂得權衡，走過(guò)彎路之后才會(huì )尋找捷徑。
所以我認為在架構師(和其它很多)的工作中最重要的部分是實(shí)踐，夸夸其談很容易，與其拽一些技術(shù)名詞，不如把你正在做的系統真正的做好。
我和大牛之間有多少距離?
跟很多人一樣，剛畢業(yè)時(shí)我覺(jué)得作為程序員，只要努力，加上少許天賦便可以獲得一些成績(jì)。
工作一段時(shí)間后，對自己和其他人的認識也越來(lái)越清晰，逐漸的發(fā)現程序員之間的差距或許比人和猴子之間的差距還大，接受這個(gè)事實(shí)這讓我郁悶了很久。
再過(guò)一段時(shí)間，發(fā)現自己已經(jīng)能夠客觀(guān)的評價(jià)自己的能力，也意識到了距離并不是那么重要，只要想辦法跑的更快，就足夠了。
【架構師的成長(cháng)之路】相關(guān)文章：
采購員的成長(cháng)之路05-12
CFO的素質(zhì)要求與成長(cháng)之路07-23
什么是系統架構師-如何成為系統架構師08-10
平面設計師成長(cháng)之路07-31
什么是系統架構師08-01
系統架構師概述10-13