古人云：“活到老，學(xué)到老。”互聯(lián)網(wǎng)算是最辛苦的行業(yè)之一，“加班”對工程師來說已是“家常便飯”。

同時互聯(lián)網(wǎng)技術(shù)又日新月異，很多工程師都疲于應(yīng)付，叫苦不堪。以至于長期以來流傳一個很廣的誤解：35 歲是程序員工作的終點。

如何在繁忙的工作中做好技術(shù)積累，構(gòu)建個人核心競爭力，相信是很多工程師同行都在思考的問題。

本文是我自己的一些總結(jié)，試圖從三個方面來解答：

• 如何學(xué)習(xí)。闡述了一些學(xué)習(xí)的原則，任何時候，遵循一些經(jīng)過檢驗的原則，都是影響效率的重要因素，正確的方法是成功的秘訣。
• 那些令人糾結(jié)的困惑。分析了我在工作中碰到和看到的一些典型困惑。提升工作和學(xué)習(xí)效率的另一個重要因素是釋惑和良好心態(tài)。
• 架構(gòu)師能力模型。讓大家對目標(biāo)所需能力有一個比較清晰的認(rèn)知，成為優(yōu)秀的架構(gòu)師是大部分初中級工程師的階段性目標(biāo)。

如何學(xué)習(xí)

在繁忙的工作中，持之以恒、不斷學(xué)習(xí)和進步是一件艱巨的任務(wù)，需要堅強的毅力和堅定的決心。

如果方法不得當(dāng)，更是事倍功半。幸好我們的古人和現(xiàn)在哲人已經(jīng)總結(jié)了很多優(yōu)秀的學(xué)習(xí)方法論。這里匯總了一些重要原則，遵循這些方法必會對大家的工作學(xué)習(xí)大有裨益。

貴在堅持

有報道指出，過去幾十年的知識量超過之前人類幾千年的知識量總和，而計算機領(lǐng)域絕對是當(dāng)代知識更新最快的領(lǐng)域之一。

因此，工程師必須要接受這樣一個現(xiàn)實，現(xiàn)在所掌握的深厚知識體系很快就會被淘汰。

要想在計算機領(lǐng)域持續(xù)做優(yōu)秀架構(gòu)師，就必須不停的學(xué)習(xí)，掌握最新技術(shù)。總之，學(xué)不可以已。

所謂“冰凍三尺，非一日之寒，水滴石穿，非一日之功”，通往架構(gòu)師的道路漫長而又艱巨，輕易放棄，則所有付出瞬間付之東流。要想成為優(yōu)秀的架構(gòu)師，貴在堅持！

雖然知識更新很快，但是基礎(chǔ)理論的變化卻非常緩慢。這就是“道”和“象”的關(guān)系，縱是世間萬象，道卻萬變不離其宗。對于那些非?；A(chǔ)的理論知識，我們需要經(jīng)常復(fù)習(xí)，也就是“學(xué)而時習(xí)之”。

重視實踐

古人云：“紙上得來終覺淺，絕知此事要躬行。” 學(xué)習(xí)領(lǐng)域有所謂 721 模型：個人的成長 70% 來自于崗位實踐，20% 來自向他人學(xué)習(xí)，10% 來自于培訓(xùn)。

雖然這種理論存在爭議，但對于工程師們來說，按照實踐、學(xué)習(xí)和培訓(xùn)的方式進行重要性排序，大致是不錯的。所以重視實踐，在實踐中成長是最重要的學(xué)習(xí)原則。

人類的認(rèn)知有兩種：感性認(rèn)知和理性認(rèn)知。這兩種認(rèn)知互相具有不可替代性。實踐很大程度來自于感性學(xué)習(xí)，看書更像是理性學(xué)習(xí)。以學(xué)開汽車做例子，很難想象什么人能夠僅僅通過學(xué)習(xí)書本知識就會開汽車。

書本知識主要是傳道——講述抽象原型，而對其具體應(yīng)用場景的講述往往含糊其辭，對抽象原型之間的關(guān)系也是淺嘗輒止。

采用同樣精確的語言去描述應(yīng)用場景和關(guān)聯(lián)關(guān)系將會失去重點，讓人摸不著頭腦。所以，僅僅通過看書來獲得成長就像是用一條腿走路。

重視實踐，充分運用感性認(rèn)知潛能，在項目中磨煉自己，才是正確的學(xué)習(xí)之道。在實踐中，在某些關(guān)鍵動作上刻意練習(xí)，也會取得事半功倍的效果。

重視交流

牛頓說：“如果說我看得比別人遠(yuǎn)一些，那是因為我站在巨人的肩膀上。”我們需要從別人身上學(xué)習(xí)。從老師、領(lǐng)導(dǎo)、同事、下屬甚至對手身上學(xué)習(xí)，是快速成長的重要手段。

向老師和領(lǐng)導(dǎo)學(xué)習(xí)已經(jīng)是人們生活習(xí)慣的一部分了。但是從同事甚至對手那里學(xué)習(xí)也很重要，因為這些人和我們自身更相似。

所以要多多觀察，取其所長，棄其所短。對于團隊的小兄弟和下屬，也要“不恥下問”。

此外，在項目中積極參與具體方案討論也非常重要。參與者先驗感知了相關(guān)背景，并且討論的觀點和建議也是綜合了發(fā)言者多種知識和技能。

所以，討論讓參與者能夠非常全面，立體地理解書本知識。同時，和高手討論，他們的觀點就會像修剪機剪樹枝一樣，快速的剪掉自己知識領(lǐng)域里面的疑惑點。

重視總結(jié)和輸出

工程師在實踐中會掌握大量細(xì)節(jié)，但是，即使掌握了所有細(xì)節(jié)，卻沒有深刻的總結(jié)和思考，也會陷入到“學(xué)而不思則罔”的境地。

成長的“量變”來自于對細(xì)節(jié)逐漸深入地把控，而真正的“質(zhì)變”來自于對“道”的更深層次的理解。

將經(jīng)驗輸出，接受別人的檢驗是高層次的總結(jié)。這種輸出不僅幫助了別人，對自身更是大有裨益。

總結(jié)的方式有很多，包括組織分享，撰寫技術(shù)文章等等。當(dāng)然“日三省吾身”也是不錯的總結(jié)方式?？傊喽嗫偨Y(jié)，多多分享，善莫大焉！

解答別人的問題也是個人成長的重要手段。有時候，某個問題自己本來不太懂，但是在給別人講解的時候卻豁然開朗。所以，“誨人不倦”利人惠己。

重視規(guī)劃

凡事預(yù)則立，不預(yù)則廢。對于漫長的學(xué)習(xí)生涯而言，好的計劃是成功的一半。

長期規(guī)劃

長期規(guī)劃的實施需要毅力和決心，但是做正確的長期規(guī)劃還需要高瞻遠(yuǎn)矚的眼界、超級敏感的神經(jīng)和中大獎的運氣。對于大部分人來說，長期規(guī)劃定主要是“定方向”。

但遵循如下原則能夠減少犯方向性錯誤的概率：

• 遠(yuǎn)離日暮西山的行業(yè)
• 做自己感興趣的事情
• 做有積累的事情
• 一邊走一邊看，切勿一條道走到黑

短期規(guī)劃

良好的短期規(guī)劃應(yīng)該在生活、成長、績效和晉升之間取得平衡。大部分公司都會制定一個考核周期——少則一個月，多則一年。

所以不妨以考核周期作為短期學(xué)習(xí)規(guī)劃周期。本質(zhì)上，規(guī)劃是一個多目標(biāo)優(yōu)化問題，它有一系列的理論方案，這里不一一細(xì)說。

基于相關(guān)理論，我給出一個簡單易行的方案：

• 確定目標(biāo)優(yōu)先級。比如：成長、生活、績效。
• 確定每個目標(biāo)的下限。從優(yōu)化理論的角度來看，這被稱為約束。比如績效必須在一般以上，之前已經(jīng)規(guī)劃好的旅行不能更改，必須讀完《Effective Java》等等。
• 優(yōu)先為下限目標(biāo)分配足夠的資源。比如，事先規(guī)劃好的旅行需要 10 天，這10天就必須預(yù)算出去。
• 按照各主目標(biāo)的順序依次分配資源。比如，最終分配給學(xué)習(xí)的時間是 10 天。
• 在給定的學(xué)習(xí)預(yù)算下，制定學(xué)習(xí)目標(biāo)，要激進。然后給出執(zhí)行方案。比如，學(xué)習(xí)目標(biāo)是掌握基本的統(tǒng)計學(xué)知識，并成為 Java 專家。

具體方案為：完成《Effective Java》、《Java Performance》、《Design Pattern》、《Head First Statistics》四本書的閱讀。

• 對規(guī)劃中的各學(xué)習(xí)任務(wù)按目標(biāo)優(yōu)先級進行排序，并最先啟動優(yōu)先級最高的任務(wù)。比如，最高優(yōu)先級是掌握統(tǒng)計理論，那么就要先看《Head First Statistics》。

對于該方案，要注意以下幾點：

• 最低目標(biāo)必須是能夠輕松達(dá)成的目標(biāo)，否則，從優(yōu)化理論的角度來講，該命題無解。比如，類似“半年內(nèi)完成晉級兩次、績效全部 S、從菜鳥成為 Java 專家”就不太適合作為最低目標(biāo)。總之，要區(qū)分理想和夢想。
• 主要目標(biāo)規(guī)劃必須具備一定的挑戰(zhàn)性，需要規(guī)劃出不可能完成的目標(biāo)。過度規(guī)劃本質(zhì)上是一種貪婪算法，目的是目標(biāo)價值最大化。

因為一切皆有變數(shù)，如果其他目標(biāo)能夠提前完成，就不妨利用這些時間去完成更多的學(xué)習(xí)目標(biāo)。總之，前途必須光明，道路必須坎坷。

• 各目標(biāo)之間不一定共享資源，規(guī)劃不一定互有沖突。

此外，短期規(guī)劃還可以從如下幾個方面進行優(yōu)化：

• 學(xué)習(xí)計劃最好能結(jié)合工作計劃，理論與實際結(jié)合，快速學(xué)以致用。比如，本季度規(guī)劃去做一些數(shù)據(jù)分析工作，那么不妨把學(xué)習(xí)目標(biāo)設(shè)置為學(xué)習(xí)統(tǒng)計知識。
• 要靈活對待規(guī)劃的目標(biāo)和具體執(zhí)行步驟，需要避免“鄭人買履”式的笑話。面臨新的挑戰(zhàn)和變化，規(guī)劃需要不斷地調(diào)整。

[[226035]]

那些令人糾結(jié)的困惑

人生是一場馬拉松，在漫長的征途中，難免有很多困惑。困惑就像枷鎖，使我們步履蹣跚，困惑就像死鎖，讓我們停滯不前。

接下來我將總結(jié)自己在工作中碰到和看到的一些典型困惑。這些困惑或者長期困擾作者本人，或者困擾我身邊的同事和朋友。

當(dāng)這些困惑被釋然之后，大家都感覺如釋重負(fù)，為下一階段的征程提供滿滿的正能量。

人生就像一場旅途，不必在乎目的地，在乎的，應(yīng)該是沿途的風(fēng)景，以及看風(fēng)景的心情。

良好的心態(tài)是技術(shù)之旅最好的伴侶。期望通過這個解惑之旅，讓大家擁有一個愉快的心情去感受漫長的學(xué)習(xí)旅途。

學(xué)無止境嗎

必須要承認(rèn)一個殘酷的現(xiàn)實：人的生命是有限的，知識卻是無限的。用有限的生命去學(xué)習(xí)無限的知識是不可能完成的任務(wù)。

一想到此，有些工程師不免產(chǎn)生一些悲觀情緒。如果方法得當(dāng)并且足夠勤奮，悲傷大可不必。

雖然，人類的整體知識體系一直在擴張。但是就很多重要的工程細(xì)分領(lǐng)域，基礎(chǔ)理論并不高深。計算機的很多重要領(lǐng)域，工程師有能力在有限時間內(nèi)抓住核心要害。

比如，密碼學(xué)被認(rèn)為是門非常高深的學(xué)科，但是一大類密碼技術(shù)的基礎(chǔ)是數(shù)論中一個非常簡單的理論——素因數(shù)分解：給出兩個素數(shù)，很容易算出它們的積，然而反過來給定兩個素數(shù)的積，分解的計算量卻非常驚人。

“一致性”算得上是計算機領(lǐng)域里面最經(jīng)典的難題，它是所有分布式系統(tǒng)的基礎(chǔ)，從多核多 CPU 到多線程，從跨機器到跨機房，無所不在。

幾乎所有的計算機從業(yè)人員都在解決這個問題，但是 Paxos 給出了一個很優(yōu)雅的解決方案。

權(quán)限管理是很多工程師的噩夢，但如果你能搞定“Attribute Based Access Control(ABAC)”和“Role-Based Access Control(RBAC)”，也能達(dá)到相當(dāng)高度。

另外，技術(shù)學(xué)習(xí)是一場對抗賽，雖然學(xué)無止境，超越大部分對手就是一種勝利。所以，以正確的學(xué)習(xí)方式，長時間投入就會形成核心競爭力。

沒有絕對高明的技術(shù)，只有真正的高手

致力于在技術(shù)上有所成就的工程師，都夢想有朝一日成為技術(shù)高手。但技術(shù)高手的標(biāo)準(zhǔn)卻存在很大的爭議。

這是一個有著悠久歷史的誤解：以某種技術(shù)的掌握作為技術(shù)高手的評判標(biāo)準(zhǔn)。

我經(jīng)常碰到這樣一些情景：因為掌握了某些技術(shù)，比如 Spring、Kafka、Elasticsearch 等，一些工程師就自封為高手。有些工程師非常仰慕別的團隊，原因竟是那個團隊使用了某種技術(shù)。

這種誤解的產(chǎn)生有幾個原因：

• 首先，技多不壓身，技術(shù)自然是掌握的越多越好，掌握很多技術(shù)的人自然不是菜鳥。
• 其次，在互聯(lián)網(wǎng)時代來臨之前，信息獲取是非常昂貴的事情。這就導(dǎo)致一項技能的掌握可以給個人甚至整個公司帶來優(yōu)勢地位。

互聯(lián)網(wǎng)時代，各種框架的出現(xiàn)以及開源的普及快速淘汰或者降低了很多技能的價值，同時降低了很多技術(shù)的學(xué)習(xí)門檻。

所以，在當(dāng)前，掌握某項技能知識只能是一個短期目標(biāo)。懷揣某些技能就沾沾自喜的人需要記?。候湴潦谷送瞬?。

所謂麻雀雖小，五臟俱全。如果讓你來做造物主，設(shè)計麻雀和設(shè)計大象的復(fù)雜度并沒有明顯區(qū)別。

一個看起來很小的業(yè)務(wù)需求，為了達(dá)到極致，所需要的技術(shù)和能力是非常綜合和高深的。

真正的高手不是拿著所掌握的技術(shù)去卡客戶需求，而是傾聽客戶的需求，給出精益求精的方案。完成客戶的需求是一場擂臺賽，真正的高手，是會見招拆招的。

不做項目就無法成長嗎

在項目中學(xué)習(xí)是最快的成長方式之一，很多工程師非常享受這個過程。但是一年到頭都做項目，你可能是在一家外包公司。

對于一個做產(chǎn)品的公司，如果年頭到年尾都在做項目，要不然就是在初步創(chuàng)業(yè)階段，要不然就是做了大量失敗的項目，總之不算是特別理想的狀態(tài)。

正常情況，在項目之間都會有一些非項目時間。在這段時間，有些同學(xué)會產(chǎn)生迷茫，成長很慢。

項目真的是越多越好嗎？答案顯然是否定的。重復(fù)的項目不會給工程師們帶來新的成長。

不停的做項目，從而缺乏學(xué)習(xí)新知識的時間，會導(dǎo)致“做而不學(xué)則殆”。真正讓工程師出類拔萃的是項目的深度，而不是不停地做項目。

所以，在項目之間的空檔期，工程師們應(yīng)該珍惜難得的喘息之機，深入思考，把項目做深，做精。

如何提高項目的深度呢？一般而言，任何項目都有一個目標(biāo)，當(dāng)項目完成后，目標(biāo)就算基本達(dá)成了。

但是，客戶真的滿意了嗎？系統(tǒng)的可用性、可靠性、可擴展性、可維護性已經(jīng)做到極致了嗎？這幾個問題的答案永遠(yuǎn)是否定的。

所以，任何一個有價值的項目，都可以一直深挖。深挖項目，深度思考還可以鍛煉工程師的創(chuàng)造力。

期望不停地做項目的人，就像一個致力于訓(xùn)練更多千里馬的人是發(fā)明不出汽車的。

鍛煉創(chuàng)造力也不是一蹴而就的事情，需要長時間地思考?？傊?，工程師們應(yīng)該總是覺得時間不夠用，畢竟時間是最寶貴的資源。

職責(zé)真的很小嗎

很多時候，一個工程師所負(fù)責(zé)系統(tǒng)的數(shù)量和團隊規(guī)模與其“江湖地位”正相關(guān)。但是，江湖地位與技術(shù)成長沒有必然關(guān)聯(lián)。

提升技術(shù)能力的關(guān)鍵是項目深度以及客戶的挑剔程度。項目越多，在單個項目中投入的時間就越少，容易陷入膚淺。

特別需要避免的是“ 在其位不謀其政”的情況。團隊越大，在管理方面需要投入的精力就越多。

在管理技巧不成熟，技術(shù)眼界不夠高的前提強行負(fù)責(zé)大團隊，可能會導(dǎo)致個人疲于應(yīng)付，團隊毫無建樹。最終“ 一將無能，累死三軍”，效果可能適得其反。

從技術(shù)發(fā)展的角度來說，技術(shù)管理者應(yīng)該關(guān)注自己所能把控的活躍項目的數(shù)量，并致力于提高活躍項目的影響力和技術(shù)深度。

團隊人數(shù)要與個人管理能力、規(guī)劃能力和需求把控能力相適應(yīng)。一份工作讓多個人來干，每個人的成長都受限。

每個人都做簡單重復(fù)的工作，對技術(shù)成長沒有任何好處。團隊管理和項目管理需要循序漸進，忌“拔苗助長”。

一定要當(dāng)老大嗎

有一些工程師的人生理想是做團隊里的技術(shù)老大，這當(dāng)然是一個值得稱贊的理想。

可是，如果整個團隊技術(shù)能力一般，發(fā)展?jié)摿σ话悖闶羌夹g(shù)最強者，這與其說是幸運，不如說是悲哀。這種場景被稱之為“武大郎開店”。

團隊里的技術(shù)頂尖高手不是不能做，但為了能夠持續(xù)成長，需要滿足如下幾個條件：

• 首先你得是行業(yè)里面的頂尖專家了——實在很難找到比你更強的人了。
• 其次，你經(jīng)常需要承擔(dān)對你自己的能力有挑戰(zhàn)的任務(wù)，但同時你擁有一批聰明能干的隊友。雖然你的技術(shù)能力最高，但是在你不熟悉的領(lǐng)域，你的隊友能夠進行探索并擴展整個團隊的知識。
• 最后，你必須要敏而好學(xué)，不恥下問。

否則，加入更強的技術(shù)團隊或許是更好的選擇，最少不是什么值得驕傲的事情。

平臺化的傳說

平臺化算得上是“高大上”的代名詞了，很多工程師擠破頭就為了和“平臺化”沾點邊。

然而和其他業(yè)務(wù)需求相比，平臺化需求并沒有本質(zhì)上的區(qū)別。無論是平臺化需求還是普通業(yè)務(wù)需求，它的價值都來自于客戶價值。

不同點如下：

• 很多平臺化需求的客戶來自于技術(shù)團隊，普通需求的客戶來自于業(yè)務(wù)方。
• 產(chǎn)品經(jīng)理不同。普通業(yè)務(wù)需求來自于產(chǎn)品經(jīng)理，平臺化需求的產(chǎn)品經(jīng)理可能就是工程師自己。長期被產(chǎn)品經(jīng)理“壓迫”的工程師們，在平臺化上終于找到“翻身農(nóng)奴把歌唱”的感覺。
• 很多平臺化的關(guān)注點是接入能力和可擴展性，而普通業(yè)務(wù)的關(guān)注點更多。

歸根結(jié)底，平臺化就是一種普通需求。在實施平臺化之前，一定要避免下面兩個誤區(qū)：

• 平臺化絕對不是諸如“統(tǒng)一”、“全面”之類形容詞的堆砌。是否需要平臺化，應(yīng)該綜合考慮：客戶數(shù)量，為客戶解決的問題，以及客戶價值是否值得平臺化的投入。
• 平臺化不是你做平臺，讓客戶來服務(wù)你。一些平臺化設(shè)計者的規(guī)劃設(shè)計里面，把大量的平臺接入工作、臟活累活交給了客戶，然后自己專注于所謂“最高大上”的功能。

恰恰相反，平臺化應(yīng)該是客戶什么都不做，所有的臟活累活都由平臺方來做。本質(zhì)上講，平臺化的價值來自于技術(shù)深度。真正體現(xiàn)技術(shù)深度的恰恰是設(shè)計者能夠很輕松的把所有的臟活累活搞定。

所以平臺化的最佳實踐是：投入最少的資源，解決最多的問題。平臺解決一切，客戶坐享其成。

搞基礎(chǔ)技術(shù)就一定很牛嗎

經(jīng)常聽到同學(xué)們表達(dá)對基礎(chǔ)技術(shù)部同學(xué)的敬仰之情，而對搞業(yè)務(wù)技術(shù)的同學(xué)表現(xiàn)出很輕視，認(rèn)為存儲、消息隊列、服務(wù)治理框架（比如美團點評內(nèi)部使用的 OCTO）、Hadoop 等才能被稱為真正的技術(shù)。事實并非如此，更基礎(chǔ)的并不一定更高深。

比如下面這個流傳很久的段子：越高級的語言就越?jīng)]有技術(shù)含量。但真是這樣嗎，就拿 Java 和 C 來說，這是完全不同的兩種語言，所需要的技能完全不同。

C 或許跟操作系統(tǒng)更加接近一點，和 CPU、內(nèi)存打交道的機會更多一點。但是為了用好 Java，程序員在面向?qū)ο?、設(shè)計模式、框架技術(shù)方面必須要非常精通。

Java 工程師轉(zhuǎn)到 C 方向確實不容易，但作者也見過很多轉(zhuǎn)到 Java 語言的 C 工程師水土不服。

基礎(chǔ)技術(shù)和業(yè)務(wù)應(yīng)用技術(shù)必然會有不同的關(guān)注點，沒有高低之分。

之所以產(chǎn)生這種誤解，有兩個原因：

• 基礎(chǔ)技術(shù)相對成熟，有比較完整的體系，這給人一個高大上的感覺。業(yè)務(wù)應(yīng)用技術(shù)相對來說，由于每個團隊使用的不一樣，所以成熟度參差不齊，影響力沒有那么大。
• 基礎(chǔ)技術(shù)的門檻相對來說高一點，考慮到影響面，對可靠性、可用性等有比較高的最低要求。但是門檻高不代表技術(shù)含量高，另外成熟技術(shù)相對來說在創(chuàng)新方面會受到很大的約束。但是最先進的技術(shù)都來自活躍的創(chuàng)新。

對比下來，業(yè)務(wù)技術(shù)和基礎(chǔ)技術(shù)各有千秋。但真正的高手關(guān)注的是解決問題，所有的技術(shù)都是技能而已。

可行性調(diào)研的那些坑

工作中開展可行性調(diào)研時有發(fā)生，做可行性調(diào)研要避免如下情況：

• 把可行性調(diào)研做成不可行性調(diào)研。這真的非常糟糕。不可行性的結(jié)論往往是：因為這樣或者那樣的原因，所以不可行。
• 避免“老鼠給貓掛鈴鐺”式的高風(fēng)險可行性方案。“天下大事必作于細(xì)”，可行性調(diào)研一定要細(xì)致入微，避免粗枝大葉。
• 避免調(diào)研時間過長。如果發(fā)現(xiàn)調(diào)研進展進入到指數(shù)級復(fù)雜度，也就是每前進一步需要之前兩倍的時間投入，就應(yīng)該果斷的停止調(diào)研。

可行性調(diào)研的結(jié)論應(yīng)該是收益與成本的折衷，格式一般如下：

• 首先明確預(yù)期的結(jié)果，并按照高中低收益進行分級。
• 闡述達(dá)成每種預(yù)期結(jié)果需要采取的措施和方案。
• 給出實施各方案需要付出的成本。

工程師天生不善溝通嗎

實際工作中，溝通所導(dǎo)致的問題層出不窮。工程師有不少是比較內(nèi)向的，總是被貼上“不善溝通”的標(biāo)簽。

實際上，溝通能力是工程師最重要的能力之一，良好的溝通是高效工作學(xué)習(xí)的基礎(chǔ)，也是通過學(xué)習(xí)可以掌握的。下面我按工程師的語言說說溝通方面的經(jīng)驗。

第一類常見的問題是溝通的可靠性。從可靠性的角度來講，溝通分為 TCP 模式和 UDP 模式。

TCP 模式的形象表述是：我知道你知道。UDP 模式的形象表述是：希望你知道。TCP 模式當(dāng)然比較可靠，不過成本比較高，UDP 模式成本低，但是不可靠。

在溝通可靠性方面，常見錯誤有如下兩種：

• 經(jīng)常聽到這樣的爭論。一方說：“我已經(jīng)告訴他了”，另一方說：“我不知道這個事情呀”。把 UDP 模式被當(dāng)作 TCP 模式來使用容易產(chǎn)生扯皮。
• 過度溝通。有些同學(xué)對溝通的可靠性產(chǎn)生了過度焦慮，不斷的重復(fù)討論已有結(jié)論問題。把 TCP 模式當(dāng)成 UDP 來使用，效率會比較低。

第二類溝通問題是時效性問題。從時效性講，溝通分為：同步模式和異步模式。

同步溝通形象地說就是：你現(xiàn)在給我聽好了。異步溝通的形象表述是：記得給我做好了。

在溝通時效性方面，有如下兩種常見錯誤：

• 已經(jīng)出現(xiàn)線上事故，緊急萬分。大家你一言，我一語，感覺事故可能和某幾個人有關(guān)，但是也不能完全確定，所以沒有通知相關(guān)人員。最終，一個普通的事故變成了嚴(yán)重事故。對于緊急的事情，必須要同步溝通。
• 半夜三點你正在熟睡，或者周末正在逛街，接到一個電話：“現(xiàn)在有個需求，能否立刻幫忙做完。”這會非常令人郁悶，因為那并不是緊急的事情。不是所有的需求都需要立刻解決。

有效溝通的一個重要原則是提前溝通。溝通本質(zhì)是信息交流和處理，可以把被溝通對象形象地比喻成串行信息處理的 CPU。

提前溝通，意味著將處理請求盡早放入處理隊列里面。下面的例子讓很多工程師深惡痛絕：一個需求策劃了 1 個月，產(chǎn)品設(shè)計了 2 周。

當(dāng)開發(fā)工程是第一次聽說該需求的時候，發(fā)現(xiàn)開發(fā)的時間是 2 天。工程師據(jù)理力爭，加班加點 1 周搞定。

最后的結(jié)論是工程師非常不給力，不配合。就像工程師討厭類似需求一樣。要協(xié)調(diào)一個大項目，希望獲得別人的配合，也需要盡早溝通。

有效溝通的另外一個重點是“不要跑題”。很多看起來很接近的問題，本質(zhì)上是完全不同的問題。

比如：一個會議的主題是“如何實施一個方案”，有人卻可能提出“是否應(yīng)該實施該方案”。

 “如何實施”和“是否應(yīng)該實施”是完全不同的兩個問題，很多看起來相關(guān)的問題實際上跑題很遠(yuǎn)。“跑題”是導(dǎo)致無效溝通的重要原因。

良好溝通的奧秘在于能掌握 TCP 模式和 UDP 模式精髓，正確判斷問題的緊急性，盡量提前溝通，避免跑題。

帶人之道

有些初為導(dǎo)師的工程師由于擔(dān)心畢業(yè)生的能力太弱，安排任務(wù)時候諄諄教誨，最后感覺還是有所顧慮，干脆自己寫代碼。

同樣的事情發(fā)生在很多剛剛管理小團隊的工程師身上。最終的結(jié)果他們：寫完所有的代碼，讓下屬無代碼可寫。

“ 事必躬親”當(dāng)然非常糟糕，最終的往往是團隊的整體績效不高，團隊成員的成長很慢，而自己卻很累。

古人說：“用人不疑，疑人不用。”這句話并非“放之四海而皆準(zhǔn)”。在古代，受限于通信技術(shù)，反饋延遲顯著，而且信息在傳遞過程中有大量噪音，變形嚴(yán)重。

在這種情況下，如果根據(jù)短期內(nèi)收集的少量變形的信息做快速決斷，容易陷于草率。在公司里，這句話用于選人環(huán)節(jié)更為恰當(dāng)，應(yīng)該改為：錄用不疑，疑人不錄。

考慮到招聘成本，就算是在錄用層面，有時候也無法做到。作為一個小團隊的管理者，能夠快速準(zhǔn)確的獲取團隊成員的各種反饋信息，完全不需要“用人不疑，疑人不用”。

用人的真正理論基礎(chǔ)來自于“探索和利用”(Exploration and Exploitation )。不能因為下屬能做什么就只讓他做什么，更不能因為下屬一次失敗就不給機會。

根據(jù)經(jīng)典的“探索和利用”(Exploration and Exploitation )理論，良好的用人方式應(yīng)該如下：

首選選擇相信，在面臨失敗后，收縮信任度。

查找失敗的原因，提供改進意見，提升下屬的能力。

總是給下屬機會，在恰當(dāng)?shù)貢r機給下屬更高的挑戰(zhàn)。 總之，蒼天大樹來自一顆小種子，要相信成長的力量。

效率、效率、效率

經(jīng)常看到有些同學(xué)給自己的績效評分是 100 分——滿分，原因是在過去一段時間太辛苦了，但最終的績效卻一般般。

天道酬勤不錯，但是天道更酬巧。工程師們都學(xué)過數(shù)據(jù)結(jié)構(gòu)，不同算法的時間復(fù)雜度的差距，僅僅通過更長的工作時間是難以彌補的。

為了提升工作學(xué)習(xí)效率，我們需要注意以下幾點：

• 主要關(guān)注效率提升。很多時候，與效率提升所帶來的收益相比，延長時間所帶來的成果往往不值得一提。
• 要有清晰的結(jié)果導(dǎo)向思維。功勞和苦勞不是一回事。
• 做正確的事情，而不僅僅正確地做事情。這是一個被不斷提起的話題，但是錯誤每天都上演。為了在規(guī)定的時間內(nèi)完成一個大項目，總是要有所取舍。

如果沒有重點，均勻發(fā)力，容易事倍功半。如果“南轅北轍”，更是可悲可嘆。

[[226036]]

架構(gòu)師能力模型

前面我們已經(jīng)講完了原則和一些困惑，那么工程師到底應(yīng)該怎么提升自己呢？

[[226037]]

成為優(yōu)秀的架構(gòu)師是大部分初中級工程師的階段性目標(biāo)，優(yōu)秀的架構(gòu)師往往具備七種核心能力：

• 編程能力
• 調(diào)試能力
• 編譯部署能力
• 性能優(yōu)化能力
• 在線運維能力
• 業(yè)務(wù)架構(gòu)能力
• 項目管理能力
• 團隊管理能力

這幾種能力之間的關(guān)系大概如上圖。編程能力、調(diào)試能力和編譯部署能力屬于最基礎(chǔ)的能力。

不能精通掌握這三種能力，很難在性能優(yōu)化能力和業(yè)務(wù)架構(gòu)能力方面有所成就。

具備了一定的性能優(yōu)化能力和業(yè)務(wù)架構(gòu)能力之后，才能在線運維能力和項目管理能力方面表現(xiàn)優(yōu)越。團隊管理能力是最高能力，它對項目管理能力的依賴度更大。

編程能力

對工程師而言，編程是最基礎(chǔ)的能力，必備技能。其本質(zhì)是一個翻譯能力，將業(yè)務(wù)需求翻譯成機器能懂的語言。

提升編程能力的書籍有很多。精通面向?qū)ο蠛驮O(shè)計模式是高效編程的基礎(chǔ)。初級工程師應(yīng)該多寫代碼、多看代碼。找高手做 Code Review，也是提升編程水平的捷徑。

調(diào)試能力

程序代碼是系統(tǒng)的靜態(tài)形式，調(diào)試的目的是通過查看程序的運行時狀態(tài)來驗證和優(yōu)化系統(tǒng)。

本質(zhì)上講，工程師們通過不斷調(diào)試可以持續(xù)強化其通過靜態(tài)代碼去預(yù)測運行狀態(tài)的能力。

所以調(diào)試能力也是工程師編程能力提升的關(guān)鍵手段。很早之前有個傳說：“調(diào)試能力有多強，編程能力就有多強。”不過現(xiàn)在很多編輯器的功能很強大，調(diào)試能力的門檻已經(jīng)大大降低。

調(diào)試能力是項目能否按時、高質(zhì)量提交的關(guān)鍵。即使一個稍具復(fù)雜度的項目，大部分工程師也無法一次性準(zhǔn)確無誤的完成。

大項目都是通過不斷地調(diào)試進行優(yōu)化和糾錯的。所以調(diào)試能力是不可或缺的能力。多寫程序，解決 Bug，多請教高手是提升調(diào)試能力的重要手段。

編譯部署能力

編譯并在線上部署運行程序是系統(tǒng)上線的最后一個環(huán)節(jié)。隨著 SOA 架構(gòu)的普及以及業(yè)務(wù)復(fù)雜度的增加，大部分系統(tǒng)只是一個完整業(yè)務(wù)的一個環(huán)節(jié)，因此，本地編譯和運行并不能完全模擬系統(tǒng)在線運行。

為了快速驗證所編寫程序的正確性，編譯并在線上部署就成了必要環(huán)節(jié)。所以編譯部署能力是一個必備技能。

讓盤根錯節(jié)的眾多子系統(tǒng)運行起來是個不小的挑戰(zhàn)。得益于 SOA 架構(gòu)的普及以及大量編譯、部署工具的發(fā)展，編譯部署的門檻已經(jīng)大大降低。

基于應(yīng)用層進行開發(fā)的公司，已經(jīng)很少有“編譯工程師”的角色了。但是對于初級工程師而言，編譯部署仍然不是一個輕松的事情。

性能優(yōu)化能力

衡量一個系統(tǒng)成功的一個重要指標(biāo)是使用量。隨著使用量的增加和業(yè)務(wù)復(fù)雜度的增加，大部分系統(tǒng)最終都會碰到性能問題。 

性能優(yōu)化能力是一個綜合能力，原因如下：

• 影響系統(tǒng)性能的因素眾多，包括：數(shù)據(jù)結(jié)構(gòu)、操作系統(tǒng)、虛擬機、CPU、存儲、網(wǎng)絡(luò)等。為了對系統(tǒng)性能進行調(diào)優(yōu)，架構(gòu)師需要掌握所有相關(guān)的技術(shù)。
• 精通性能優(yōu)化意味著深刻理解可用性、可靠性、一致性、可維護性、可擴展性等的本質(zhì)。
• 性能優(yōu)化與業(yè)務(wù)強耦合，最終所采取的手段往往是折衷的結(jié)果。所以，性能優(yōu)化要深諳妥協(xié)的藝術(shù)。

可以說，性能優(yōu)化能力是工程師們成長過程中各種技能開始融會貫通的一個標(biāo)志。

市場上還有很多與性能優(yōu)化相關(guān)的書籍，大家可以參考。多多閱讀開源框架中關(guān)于性能優(yōu)化方面的文檔和代碼也不失為好的提升手段。動手解決線上性能問題也是提升性能優(yōu)化能力的關(guān)鍵。

如果有機會，跟著高手學(xué)習(xí)，分析性能優(yōu)化解決方案案例，也是快速提升性能優(yōu)化能力的手段。

在線運維能力

如果說性能優(yōu)化能力體現(xiàn)的是架構(gòu)師的靜態(tài)思考能力，在線運維能力考驗的就是動態(tài)反應(yīng)能力。

殘酷的現(xiàn)實是，無論程序多么完美，Bug 永遠(yuǎn)存在。與此同時，職位越高、責(zé)任越大，很多架構(gòu)師需要負(fù)責(zé)非常重要的在線系統(tǒng)。

對于線上故障，如果不能提前預(yù)防以及快速解決，損失可能不堪設(shè)想，所以在線運維能力是優(yōu)秀架構(gòu)師的必備技能。

為了對線上故障進行快速處理，標(biāo)準(zhǔn)化的監(jiān)控、上報、升級，以及基本應(yīng)對機制當(dāng)然很重要。

通過所觀察到的現(xiàn)象，快速定位、緩解以及解決相關(guān)癥狀也相當(dāng)關(guān)鍵。這要求架構(gòu)師對故障系統(tǒng)的業(yè)務(wù)、技術(shù)具備通盤解讀能力。

解決線上故障的架構(gòu)師就好比一個在參加比賽 F1 的車手。賽車手必須要了解自身、賽車、對手、同伴、天氣、場地等所有因素，快速決策，不斷調(diào)整。

架構(gòu)師必須要了解所有技術(shù)細(xì)節(jié)、業(yè)務(wù)細(xì)節(jié)、處理規(guī)范、同伴等眾多因素，快速決斷，迅速調(diào)整。

在線運維本質(zhì)上是一個強化學(xué)習(xí)的過程。很多能力都可以通過看書、查資料來完成，但在線運維能力往往需要大量的實踐來提升。

業(yè)務(wù)架構(gòu)能力

工程師抱怨產(chǎn)品經(jīng)理的故事屢見不鮮，抱怨最多的主要原因來自于需求的頻繁變更。

需求變更主要有兩個來源：第一個原因是市場改變或戰(zhàn)略調(diào)整，第二個原因是偽需求。

對于第一個原因，無論是工程師還是產(chǎn)品經(jīng)理，都只能無奈的接受。優(yōu)秀的架構(gòu)師應(yīng)該具備減少第二種原因所導(dǎo)致的需求變更的概率。

偽需求的產(chǎn)生有兩個原因：

• 需求傳遞變形。從信息論的角度來講，任何溝通都是一個編碼和解碼的過程。典型的需求從需求方到產(chǎn)品經(jīng)理，最終到開發(fā)工程師，最少需要經(jīng)歷三次編碼和解碼過程。

而信息的每一次傳遞都存在一些損失并帶來一些噪音，這導(dǎo)致有些時候開發(fā)出來的產(chǎn)品完全對不上需求。此外，需求方和產(chǎn)品經(jīng)理在需求可行性、系統(tǒng)可靠性，開發(fā)成本控制方面的把控比較弱，也會導(dǎo)致需求變形。

• 需求方完全沒有想好自己的需求。優(yōu)秀的架構(gòu)師應(yīng)該具備辨別真?zhèn)涡枨蟮哪芰?。?yīng)該花時間去了解客戶的真實業(yè)務(wù)場景，具備較強的業(yè)務(wù)抽象能力，洞悉客戶的真實需求。

系統(tǒng)的真正實施方是工程師，在明確客戶真實需求后，高明的架構(gòu)師應(yīng)該具備準(zhǔn)確判斷項目對可行性、可靠性、可用性等方面的要求，并能具備成本意識。

最后，由于需求與在線系統(tǒng)的緊耦合關(guān)系，掌握在線系統(tǒng)的各種細(xì)節(jié)也是成功的業(yè)務(wù)架構(gòu)的關(guān)鍵。隨著級別的提升，工程師所面對的需求會越來越抽象。承接抽象需求，提供抽象架構(gòu)是架構(gòu)師走向卓越的必經(jīng)之途。

市場上有一些關(guān)于如何成為架構(gòu)師的書，大家可以參考。但是架構(gòu)能力的提升，實踐可能是更重要的方式。

業(yè)務(wù)架構(gòu)師應(yīng)該關(guān)注客戶的痛點而不是 PRD 文檔，應(yīng)該深入關(guān)注真實業(yè)務(wù)。掌握現(xiàn)存系統(tǒng)的大量技術(shù)和業(yè)務(wù)細(xì)節(jié)也是業(yè)務(wù)架構(gòu)師的必備知識。

項目管理能力

作為工業(yè)時代的產(chǎn)物，分工合作融入在互聯(lián)網(wǎng)項目基因里面。架構(gòu)師也需要負(fù)責(zé)幾個重大項目才能給自己正名。

以架構(gòu)師角色去管理項目，業(yè)務(wù)架構(gòu)能力當(dāng)然是必備技能。此外，人員管理和成本控制意識也非常重要。

項目管理還意味著要有一個大心臟。重大項目涉及技術(shù)攻關(guān)、人員變動、需求更改等眾多可變因素。面臨各種變化，還要確保目標(biāo)順利達(dá)成，需要較強的抗壓能力。

人員管理需要注意的方面包括：

• 知人善用，意味著架構(gòu)師需要了解每個參與者的硬技能和軟素質(zhì)。同時，關(guān)注團隊成員在項目過程中的表現(xiàn)，按能分配。
• 優(yōu)化關(guān)系，意味著管理團隊的情緒，畢竟項目的核心是團隊，有士氣的團隊才能高效達(dá)成目標(biāo)。
• 簡化溝通，意味著快速決策，該妥協(xié)的時候妥協(xié)，權(quán)責(zé)分明。
• 堅持真理，意味著頂住壓力，在原則性問題上絕不退步。

成本控制意味著對項目進行精細(xì)化管理，需要遵循如下幾個原則：

• 以終為始、確定里程碑。為了達(dá)成目標(biāo)，所有的計劃必須以終為始來制定。將大項目分解成幾個小階段，控制每個階段的里程碑可以大大降低項目失敗的風(fēng)險。
• 把控關(guān)鍵路徑和關(guān)鍵項目。按照關(guān)鍵路徑管理理論（CPM）的要求，架構(gòu)師需要確定每個子項目的關(guān)鍵路徑，確定其最早和最晚啟動時間。同時，架構(gòu)師需要關(guān)注那些可能會導(dǎo)致項目整體延期的關(guān)鍵節(jié)點，并集中力量攻破。
• 掌控團隊成員的張弛度。大項目持續(xù)時間會比較長，也包含不同工種。項目實施是一個不斷變化的動態(tài)過程，在這個過程中不是整個周期都很緊張，不是所有的工種都一樣忙。

優(yōu)秀的架構(gòu)師必須要具備精細(xì)閱讀整體項目以及快速反應(yīng)和實時調(diào)整的能力。這不僅僅可以大大降低項目成本，還可以提高產(chǎn)出質(zhì)量和團隊滿意度?？傮w來說，“前緊后松”是項目管理的一個重要原則。

項目管理方面的書籍很多。但是，提高業(yè)務(wù)架構(gòu)能力同樣重要。積極參與大項目并觀察別人管理項目的方式也是非常重要的提升手段。

團隊管理能力

不想做 CTO 的工程師不是一個好的架構(gòu)師。走向技術(shù)管理應(yīng)該是工程師的一個主流職業(yè)規(guī)劃。團隊管理的一個核心能力就是規(guī)劃能力，這包括項目規(guī)劃和人員規(guī)劃。

良好的規(guī)劃需要遵循如下原則：

• 規(guī)劃是利益的博弈。良好的規(guī)劃上面對得起老板，中間對得起自己，下面對得起團隊。在三者利益者尋找平衡點，實現(xiàn)多方共贏考驗著管理者的智慧和精細(xì)拿捏的能力。
• 任何規(guī)劃都比沒有規(guī)劃好。沒有規(guī)劃的團隊就是沒頭的蒼蠅，不符合所有人的利益。
• 規(guī)劃不是本本主義。市場在變，團隊在變，規(guī)劃也不應(yīng)該一成不變。
• 客戶至上的是項目規(guī)劃的出發(fā)點。
• 就人員規(guī)劃而言，規(guī)劃需要考量團隊成員的能力、績效、成長等多方面的因素。

市場上有很多規(guī)劃管理方面的書籍，值得閱讀。最優(yōu)化理論雖然是技術(shù)書籍，但它是規(guī)劃的理論基礎(chǔ)，所以不妨多看看翻閱一下。

從自我規(guī)劃開始，多多學(xué)習(xí)別人的規(guī)劃也是規(guī)劃能力提升的重要手段。

總結(jié)

因為受邀去做一個關(guān)于“一邊工作，一邊學(xué)習(xí)”的分享，作者花了一段時間去思考和匯總學(xué)習(xí)方法論，接著每天不斷地采集謠言并嘗試解惑，再根據(jù)個人經(jīng)驗繪制出優(yōu)秀架構(gòu)師的能力模型，最后匯集成文。

文章系統(tǒng)性地闡述了學(xué)習(xí)原則、分析了常見困惑，并制定明確學(xué)習(xí)目標(biāo)，期望對工程師們的工作學(xué)習(xí)有所幫助。

需要申明的是，文章內(nèi)容掛一漏萬，所謂的架構(gòu)師能力模型也是作者的個人觀點。歡迎大家在評論中分享自己在學(xué)習(xí)成長方面的心得。