原文：https://tech.meituan.com/study_vs_work.html

工作中如何做好技術積累

劉丁 ·2018-04-16 19:34

引言

古人云：“活到老其徙，學到老夷野。”互聯(lián)網算是最辛苦的行業(yè)之一守问，“加班”對工程師來說已是“家常便飯”署恍，同時互聯(lián)網技術又日新月異，很多工程師都疲于應付侦厚，叫苦不堪。以至于長期以來流傳一個很廣的誤解：35歲是程序員工作的終點拙徽。

如何在繁忙的工作中做好技術積累刨沦，構建個人核心競爭力，相信是很多工程師同行都在思考的問題膘怕。本文是我自己的一些總結想诅，試圖從三個方面來解答：

• 第一部分闡述了一些學習的原則。任何時候岛心，遵循一些經過檢驗的原則来破，都是影響效率的重要因素，正確的方法是成功的秘訣忘古。

• 提升工作和學習效率的另一個重要因素是釋惑和良好心態(tài)徘禁。第二部分分析了我在工作中碰到和看到的一些典型困惑。

• 成為優(yōu)秀的架構師是大部分初中級工程師的階段性目標髓堪。第三部分剖析架構師的能力模型送朱，讓大家對目標所需能力有一個比較清晰的認知。

如何學習

在繁忙的工作中干旁，持之以恒驶沼、不斷學習和進步是一件艱巨的任務，需要堅強的毅力和堅定的決心争群。如果方法不得當回怜，更是事倍功半。幸好我們的古人和現在哲人已經總結了很多優(yōu)秀的學習方法論祭阀，這里匯總了一些重要原則鹉戚。遵循這些方法必會對大家的工作學習大有裨益鲜戒。

貴在堅持

有報道指出，過去幾十年的知識量超過之前人類幾千年的知識量總和抹凳。而計算機領域絕對是當代知識更新最快的領域之一遏餐，因此，工程師必須要接受這樣一個現實赢底，現在所掌握的深厚知識體系很快就會被淘汰失都。要想在計算機領域持續(xù)做優(yōu)秀架構師，就必須不停的學習幸冻，掌握最新技術粹庞。總之洽损，學不可以已庞溜。

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

雖然知識更新很快，但是基礎理論的變化卻非常緩慢普泡。這就是“道”和“象”關系播掷，縱是世間萬象，道卻萬變不離其宗劫哼。對于那些非扯Ｅ浚基礎的理論知識割笙，我們需要經常復習权烧，也就是“學而時習之”褐桌。

重視實踐

古人云：“紙上得來終覺淺骗随，絕知此事要躬行”簧ィ” 學習領域有所謂721模型：個人的成長70%來自于崗位實踐乱顾，20%來自向他人學習板祝，10%來自于培訓。雖然這種理論存在爭議走净，但對于工程師們來說券时，按照實踐孤里、學習和培訓的方式進行重要性排序，大致是不錯的橘洞。所以重視實踐捌袜，在實踐中成長是最重要的學習原則。

人類的認知有兩種：感性認知和理性認知炸枣。這兩種認知互相不可替代性虏等。實踐很大程度來自于感性學習，看書更像是理性學習适肠。以學開汽車做例子霍衫，很難想象什么人能夠僅僅通過學習書本知識就會開汽車。

書本知識主要是傳道——講述抽象原型侯养，而對其具體應用場景的講述往往含糊其辭敦跌，對抽象原型之間的關系也是淺嘗輒止。采用同樣精確的語言去描述應用場景和關聯(lián)關系將會失去重點逛揩，讓人摸不著頭腦峰髓。所以，僅僅通過看書來獲得成長就像是用一條腿走路息尺。

重視實踐携兵，充分運用感性認知潛能，在項目中磨煉自己搂誉，才是正確的學習之道徐紧。在實踐中，在某些關鍵動作上刻意練習炭懊，也會取得事半功倍的效果并级。

重視交流

牛頓說：“如果說我看得比別人遠一些，那是因為我站在巨人的肩膀上侮腹〕氨蹋”我們需要從別人身上學習。從老師父阻、領導愈涩、同事、下屬甚至對手身上學習加矛，是快速成長的重要手段履婉。

向老師和領導學習已經是人們生活習慣的一部分了。但是從同事甚至對手那里學習也很重要斟览，因為這些人和我們自身更相似毁腿。所以要多多觀察，取其所長，棄其所短已烤。對于團隊的小兄弟和下屬鸠窗，也要“不恥下問”。

此外胯究，在項目中積極參與具體方案討論也非常重要塌鸯。參與者先驗感知了相關背景，并且討論的觀點和建議也是綜合了發(fā)言者多種知識和技能唐片。所以丙猬，討論讓參與者能夠非常全面，立體地理解書本知識费韭。同時茧球，和高手討論，他們的觀點就會像修剪機剪樹枝一樣星持，快速的剪掉自己知識領域里面的疑惑點抢埋。

重視總結和輸出

工程師在實踐中會掌握大量細節(jié)，但是督暂，即使掌握了所有細節(jié)揪垄，卻沒有深刻的總結和思考，也會陷入到“學而不思則罔”的境地逻翁。成長的“量變”來自于對細節(jié)的逐漸深入地把控饥努，而真正的“質變”來自于對“道”的更深層次的理解。

將經驗輸出八回，接受別人的檢驗是高層次的總結酷愧。這種輸出不僅幫助了別人，對自身更是大有裨益缠诅∪茉。總結的方式有很多，包括組織分享管引，撰寫技術文章等等士败。當然“日三省吾身”也是不錯的總結方式∪彀椋總之谅将，多多總結，多多分享噩翠，善莫大焉戏自！

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

重視規(guī)劃

凡事預則立，不預則廢狞洋。對于漫長的學習生涯而言弯淘，好的計劃是成功的一半。

長期規(guī)劃

長期規(guī)劃的實施需要毅力和決心吉懊，但是做正確的長期規(guī)劃還需要高瞻遠矚的眼界庐橙、超級敏感的神經和中大獎的運氣。對于大部分人來說借嗽，長期規(guī)劃定主要是“定方向”态鳖。但遵循如下原則能夠減少犯方向性錯誤的概率：

• 遠離日暮西山的行業(yè)。

• 做自己感興趣的事情恶导。

• 做有積累的事情浆竭。

• 一邊走一邊看，切勿一條道走到黑惨寿。

短期規(guī)劃

良好的短期規(guī)劃應該在生活邦泄、成長、績效和晉升之間取得平衡裂垦。大部分公司都會制定一個考核周期——少則一個月顺囊，多則一年。所以不妨以考核周期作為短期學習規(guī)劃周期蕉拢。本質上包蓝，規(guī)劃是一個多目標優(yōu)化問題，它有一系列的理論方案企量，這里不一一細說测萎。基于相關理論届巩，我給出一個簡單易行的方案：

• 確定目標優(yōu)先級硅瞧。比如：成長、生活恕汇、績效腕唧。

• 確定每個目標的下限。從優(yōu)化理論的角度來看瘾英，這被稱為約束枣接。比如績效必須在一般以上，之前已經規(guī)劃好的旅行不能更改缺谴，必須讀完《Effective Java》等等但惶。

• 優(yōu)先為下限目標分配足夠的資源。比如，事先規(guī)劃好的旅行需要10天膀曾，這10天就必須預算出去县爬。

• 按照各主目標的順序依次分配資源。比如添谊，最終分配給學習的時間是10天财喳。

• 在給定的學習預算下，制定學習目標斩狱，要激進耳高。然后給出執(zhí)行方案。比如所踊，學習目標是掌握基本的統(tǒng)計學知識祝高，并成為Java專家。具體方案為：完成《Effective Java》污筷、《Java Performance》工闺、《Design Pattern》、《Head First Statistics》四本書的閱讀瓣蛀。

• 對規(guī)劃中的各學習任務按目標優(yōu)先級進行排序陆蟆，并最先啟動優(yōu)先級最高的任務。比如惋增，最高優(yōu)先級是掌握統(tǒng)計理論叠殷，那么就要先看《Head First Statistics》。

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

• 最低目標必須能夠輕松達成的目標林束，否則，從優(yōu)化理論的角度來講稽亏，該命題無解壶冒。比如，類似“半年內完成晉級兩次截歉、績效全部S胖腾、從菜鳥成為Java專家”就不太合適作為最低目標”袼桑總之咸作，要區(qū)分理想和夢想。

• 主要目標規(guī)劃必須具備一定的挑戰(zhàn)性宵睦，需要規(guī)劃出不可能完成的目標记罚。過度規(guī)劃本質上是一種貪婪算法，目的是目標價值最大化壳嚎。因為一切皆有變數桐智，如果其他目標能夠提前完成末早，就不妨利用這些時間去完成更多的學習目標〗褪梗總之荐吉，前途必須光明焙糟，道路必須坎坷口渔。

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

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

• 學習計劃最好能結合工作計劃，理論聯(lián)系實際結合悦穿，快速學以致用攻礼。比如，本季度規(guī)劃去做一些數據分析工作栗柒，那么不妨把學習目標設置為學習統(tǒng)計知識礁扮。

• 要靈活對待規(guī)劃的目標和具體執(zhí)行步驟，需要避免“鄭人買履”式的笑話瞬沦。面臨新的挑戰(zhàn)和變化太伊，規(guī)劃需要不斷地調整。

那些令人糾結的困惑

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

接下來我將總結自己在工作中碰到和看到的一些典型困惑名扛。這些困惑或者長期困擾作者本人，或者困擾我身邊的同事和朋友茧痒。當這些困惑被釋然之后罢洲，大家都感覺如重獲釋，為下一階段的征程提供滿滿的正能量文黎。人生就像一場旅途惹苗，不必在乎目的地，在乎的耸峭，應該是沿途的風景桩蓉，以及看風景的心情。良好的心態(tài)是技術之旅最好的伴侶劳闹。期望通過這個解惑之旅院究，讓大家擁有一個愉快的心情去感受漫長的學習旅途洽瞬。

學無止境嗎

必須要承認一個殘酷的現實：人的生命是有限的，知識卻是無限的业汰。用有限的生命去學習無限的知識是不可能完成的任務伙窃。一想到此，有些工程師不免產生一些悲觀情緒样漆。如果方法得當并且足夠勤奮为障，悲傷大可不必。

雖然放祟，人類的整體知識體系一直在擴張鳍怨。但是就很多重要的工程細分領域，基礎理論并不高深跪妥。計算機的很多重要領域鞋喇，工程師有能力在有限時間內抓住核心要害。

比如眉撵，密碼學被認為是門非常高深的學科侦香，但是一大類密碼技術的基礎是數論中一個非常簡單的理論——素因數分解：給出兩個素數，很容易算出它們的積纽疟，然而反過來給定兩個素數的積罐韩，分解的計算量卻非常驚人。

“一致性”算得上是計算機領域里面最經典的難題仰挣，它是所有分布式系統(tǒng)的基礎伴逸，從多核多CPU到多線程，從跨機器到跨機房膘壶，無所不在错蝴，幾乎所有的計算機從業(yè)人員都在解決這個問題，但是Paxos給出了一個很優(yōu)雅的解決方案颓芭。

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

另外官紫，技術學習是一場對抗賽，雖然學無止境州藕，超越大部分對手就是一種勝利束世。所以，以正確的學習方式床玻，長時間投入就會形成核心競爭力毁涉。

沒有絕對高明的技術，只有真正的高手

致力于在技術上有所成就的工程師锈死，都夢想有朝一日成為技術高手贫堰。但技術高手的標準卻存在很大的爭議穆壕。這是一個有著悠久歷史的誤解：以某種技術的掌握作為技術高手的評判標準。我經常碰到這樣一些情景：因為掌握了某些技術其屏，比如Spring喇勋、Kafka、Elasticsearch等偎行，一些工程師就自封為高手川背。有些工程師非常仰慕別的團隊，原因竟是那個團隊使用了某種技術睦优。

這種誤解的產生有幾個原因：首先渗常，技多不壓身壮不，技術自然是掌握的越多越好汗盘，掌握很多技術的人自然不是菜鳥。其次询一，在互聯(lián)網時代來臨之前隐孽，信息獲取是非常昂貴的事情。這就導致一項技能的掌握可以給個人甚至整個公司帶來優(yōu)勢地位健蕊×庹螅互聯(lián)網時代，各種框架的出現以及開源的普及快速淘汰或者降低了很多技能的價值缩功，同時降低了很多技術的學習門檻晴及。所以，在當前嫡锌，掌握某項技能知識只能是一個短期目標虑稼。懷揣某些技能就沾沾自喜的人需要記住：驕傲使人退步势木。

所謂麻雀雖小蛛倦，五臟俱全。如果讓你來做造物主啦桌，設計麻雀和設計大象的復雜度并沒有明顯區(qū)別溯壶。一個看起來很小的業(yè)務需求，為了達到極致甫男，所需要的技術和能力是非常綜合和高深的且改。真正的高手不是拿著所掌握的技術去卡客戶需求，而是傾聽客戶的需求板驳，給出精益求精的方案又跛。完成客戶的需求是一場擂臺賽，真正的高手笋庄，是會見招拆招的效扫。

不做項目就無法成長嗎

在項目中學習是最快的成長方式之一倔监，很多工程師非常享受這個過程。但是一年到頭都做項目菌仁，你可能是在一家外包公司浩习。對于一個做產品的公司，如果年頭到年尾都在做項目济丘，要不然就是在初步創(chuàng)業(yè)階段谱秽，要不然就是做了大量失敗的項目，總之不算是特別理想的狀態(tài)摹迷。正常情況疟赊，在項目之間都會有一些非項目時間。在這段時間峡碉，有些同學會產生迷茫近哟，成長很慢。

項目真的是越多越好嗎鲫寄？答案顯然是否定的吉执。重復的項目不會給工程師們帶來新的成長。不停的做項目地来，從而缺乏學習新知識的時間戳玫，會導致“做而不學則殆”。真正讓工程師出類拔萃的是項目的深度未斑，而不是不停地做項目咕宿。所以，在項目之間的空檔期蜡秽，工程師們應該珍惜難得的喘息之機府阀，深入思考，把項目做深载城，做精肌似。

如何提高項目的深度呢？一般而言诉瓦，任何項目都有一個目標川队，當項目完成后，目標就算基本達成了睬澡。但是固额，客戶真的滿意了嗎？系統(tǒng)的可用性煞聪、可靠性斗躏、可擴展性、可維護性已經做到極致了嗎昔脯？這幾個問題的答案永遠是否定的啄糙。所以笛臣，任何一個有價值的項目，都可以一直深挖隧饼。深挖項目沈堡，深度思考還可以鍛煉工程師的創(chuàng)造力。期望不停地做項目的人燕雁，就像一個致力于訓練更多千里馬的人是發(fā)明不出汽車的诞丽。鍛煉創(chuàng)造力也不是一蹴而就的事情，需要長時間地思考拐格∩猓總之，工程師們應該總是覺得時間不夠用捏浊，畢竟時間是最寶貴的資源懂衩。

職責真的很小嗎

很多時候，一個工程師所負責系統(tǒng)的數量和團隊規(guī)模與其“江湖地位”正相關呛伴。但是勃痴，江湖地位與技術成長沒有必然關聯(lián)谒所。提升技術能力的關鍵是項目深度以及客戶的挑剔程度热康。項目越多，在單個項目中投入的時間就越少劣领，容易陷入膚淺姐军。特別需要避免的是“ 在其位不謀其政”的情況。團隊越大尖淘，在管理方面需要投入的精力就越多奕锌。在管理技巧不成熟，技術眼界不夠高的前提強行負責大團隊村生，可能會導致個人疲于應付惊暴，團隊毫無建樹。最終“ 一將無能趁桃，累死三軍”辽话，效果可能適得其反。

從技術發(fā)展的角度來說卫病，技術管理者應該關注自己所能把控的活躍項目的數量油啤，并致力于提高活躍項目的影響力和技術深度。團隊人數要與個人管理能力蟀苛、規(guī)劃能力和需求把控能力相適應益咬。一份工作讓多個人來干，每個人的成長都受限帜平。每個人都做簡單重復的工作幽告，對技術成長沒有任何好處梅鹦。團隊管理和項目管理需要循序漸進，忌“拔苗助長”冗锁。

一定要當老大嗎

有一些工程師的人生理想是做團隊里的技術老大帘瞭，這當然是一個值得稱贊的理想≥锛ィ可是蝶念，如果整個團隊技術能力一般吧趣，發(fā)展?jié)摿σ话憷染担闶羌夹g最強者嫩实，這與其說是幸運闪幽，不如說是悲哀跪者。這種場景被稱之為“武大郎開店”堪夭。 團隊里的技術頂尖高手不是不能做廷支，但為了能夠持續(xù)成長粘室，需要滿足如下幾個條件：

• 首先你得是行業(yè)里面的頂尖專家了——實在很難找到比你更強的人了马昙！

• 其次桃犬，你經常需要承擔對你自己的能力有挑戰(zhàn)的任務，但同時你擁有一批聰明能干的隊友行楞。雖然你的技術能力最高攒暇，但是在你不熟悉的領域，你的隊友能夠進行探索并擴展整個團隊的知識子房。

• 最后形用，你必須要敏而好學，不恥下問证杭。

否則田度，加入更強的技術團隊或許是更好的選擇，最少不是什么值得驕傲的事情解愤。

平臺化的傳說

平臺化算得上是“高大上”的代名詞了镇饺，很多工程師擠破頭就為了和“平臺化”沾點邊。然而和其他業(yè)務需求相比送讲，平臺化需求并沒有本質上的區(qū)別奸笤。無論是平臺化需求還是普通業(yè)務需求，它的價值都來自于客戶價值李茫。不同點如下：

• 很多平臺化需求的客戶來自于技術團隊揭保，普通需求的客戶來自于業(yè)務方。

• 產品經理不同魄宏。普通業(yè)務需求來自于產品經理秸侣，平臺化需求的產品經理可能就是工程師自己。長期被產品經理“壓迫”的工程師們，在平臺化上終于找到“翻身農奴把歌唱”的感覺味榛。

• 很多平臺化的關注點是接入能力和可擴展性椭坚，而普通業(yè)務的關注點更多。

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

• 平臺化絕對不是諸如“統(tǒng)一”频轿、“全面”之類形容詞的堆砌垂涯。是否需要平臺化，應該綜合考慮：客戶數量航邢，為客戶解決的問題耕赘，以及客戶價值是否值得平臺化的投入。

• 平臺化不是你做平臺膳殷，讓客戶來服務你操骡。一些平臺化設計者的規(guī)劃設計里面，把大量的平臺接入工作赚窃、臟活累活交給了客戶册招，然后自己專注于所謂“最高大上”的功能。恰恰相反勒极，平臺化應該是客戶什么都不做是掰，所有的臟活累活都由平臺方來做。本質上講河质，平臺化的價值來自于技術深度冀惭。真正體現技術深度的恰恰是設計者能夠很輕松的把所有的臟活累活搞定。

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

搞基礎技術就一定很牛嗎

經常聽到同學們表達對基礎技術部同學的敬仰之情，而對搞業(yè)務技術的同學表現出很輕視划址，認為存儲扔嵌、消息隊列、服務治理框架（比如美團點評內部使用的OCTO）夺颤、Hadoop等才能被稱為真正的技術痢缎。事實并非如此，更基礎的并不一定更高深世澜。

比如下面這個流傳很久的段子：越高級的語言就越沒有技術含量独旷。但真是這樣嗎，就拿Java和C來說，這是完全不同的兩種語言嵌洼，所需要的技能完全不同案疲。C或許跟操作系統(tǒng)更加接近一點，和CPU麻养、內存打交道的機會更多一點褐啡。但是為了用好Java，程序員在面向對象鳖昌、設計模式备畦、框架技術方面必須要非常精通。Java工程師轉到C方向確實不容易许昨，但作者也見過很多轉到Java語言的C工程師水土不服萍恕。

基礎技術和業(yè)務應用技術必然會有不同的關注點，沒有高低之分车要。之所以產生這種誤解允粤，有兩個原因：

• 基礎技術相對成熟，有比較完整的體系翼岁，這給人一個高大上的感覺类垫。業(yè)務應用技術相對來說，由于每個團隊使用的不一樣琅坡，所以成熟度參差不齊悉患，影響力沒有那么大。

• 基礎技術的門檻相對來說高一點榆俺，考慮到影響面售躁，對可靠性、可用性等有比較高的最低要求茴晋。但是門檻高不代表技術含量高陪捷，另外成熟技術相對來說在創(chuàng)新方面會受到很大的約束。但是最先進的技術都來自活躍的創(chuàng)新诺擅。

對比下來市袖，業(yè)務技術和基礎技術各有千秋。但真正的高手關注的是解決問題烁涌，所有的技術都是技能而已苍碟。

可行性調研的那些坑

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

• 把可行性調研做成不可行性調研撮执。這真的非常糟糕微峰。不可行性的結論往往是：因為這樣或者那樣的原因，所以不可行抒钱。

• 避免“老鼠給貓掛鈴鐺”式的高風險可行性方案蜓肆⊙湛“天下大事必作于細”，可行性調研一定要細致入微症杏，避免粗枝大葉装获。

• 避免調研時間過長。如果發(fā)現調研進展進入到指數級復雜度厉颤，也就是每前進一步需要之前兩倍的時間投入穴豫，就應該果斷的停止調研。

可行性調研的結論應該是收益與成本的折衷逼友，格式一般如下：

• 首先明確預期的結果精肃，并按照高中低收益進行分級。

• 闡述達成每種預期結果需要采取的措施和方案帜乞。

• 給出實施各方案需要付出的成本司抱。

工程師天生不善溝通嗎

實際工作中，溝通所導致的問題層出不窮黎烈。工程師有不少是比較內向的习柠，總是被貼上“不善溝通”的標簽。實際上照棋，溝通能力是工程師最重要的能力之一资溃，良好的溝通是高效工作學習的基礎，也是通過學習可以掌握的烈炭。下面我按工程師的語言說說溝通方面的經驗溶锭。

第一類常見的問題是溝通的可靠性。從可靠性的角度來講符隙，溝通分為TCP模式和UDP模式趴捅。TCP模式的形象表述是：我知道你知道。UDP模式的形象表述是：希望你知道霹疫。TCP模式當然比較可靠拱绑，不過成本比較高，UDP模式成本低更米，但是不可靠欺栗。在溝通可靠性方面，常見錯誤有如下兩種：

• 經常聽到的這樣的爭論征峦。一方說：“我已經告訴他了”，另一方說：“我不知道這個事情呀”消请。把UDP模式被當作TCP模式來使用容易產生扯皮栏笆。

• 過度溝通。有些同學對溝通的可靠性產生了過度焦慮，不斷的重復討論已有結論問題。把TCP模式當成UDP來使用蹂风，效率會比較低。

第二類溝通問題是時效性問題姥闭。從時效性講铜跑，溝通分為：同步模式和異步模式坦弟。同步溝通形象地說就是：你現在給我聽好了赤炒。異步溝通的形象表述是：記得給我做好了。在溝通時效性方面绢记，有如下兩種常見錯誤：

• 已經出現線上事故，緊急萬分正卧。大家你一言蠢熄，我一語，感覺事故可能和某幾個人有關炉旷，但是也不能完全確定签孔，所以沒有通知相關人員。最終窘行，一個普通的事故變成了嚴重事故饥追。對于緊急的事情，必須要同步溝通罐盔。

• 半夜三點你正在熟睡但绕，或者周末正在逛街，接到一個電話：“現在有個需求惶看，能否立刻幫忙做完捏顺。”這會非常令人郁悶纬黎，因為那并不是緊急的事情幅骄。不是所有的需求都需要立刻解決。

有效溝通的一個重要原則是提前溝通本今。溝通本質是信息交流和處理拆座，可以把被溝通對象形象地比喻成串行信息處理的CPU。提前溝通冠息，意味著將處理請求盡早放入處理隊列里面挪凑。下面的例子讓很多工程師深惡痛絕：一個需求策劃了1個月，產品設計了2周逛艰。當開發(fā)工程是第一次聽說該需求的時候岖赋，發(fā)現開發(fā)的時間是2天。工程師據理力爭瓮孙，加班加點1周搞定唐断。最后的結論是工程師非常不給力，不配合杭抠。就像工程師討厭類似需求一樣脸甘。要協(xié)調一個大項目，希望獲得別人的配合偏灿，也需要盡早溝通丹诀。

有效溝通的另外一個重點是“不要跑題”。很多看起來很接近的問題翁垂，本質上是完全不同的問題铆遭。比如：一個會議的主題是“如何實施一個方案”，有人卻可能提出“是否應該實施該方案”沿猜。 “如何實施”和“是否應該實施”是完全不同的兩個問題枚荣，很多看起來相關的問題實際上跑題很遠√浼纾“跑題”是導致無效溝通的重要原因橄妆。

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

帶人之道

有些初為導師的工程師由于擔心畢業(yè)生的能力太弱赦拘，安排任務時候諄諄教誨慌随，最后感覺還是有所顧慮，干脆自己寫代碼躺同。同樣的事情發(fā)生在很多剛剛管理小團隊的工程師身上阁猜。最終的結果他們：寫完所有的代碼，讓下屬無代碼可寫笋籽”哪“ 事必躬親”當然非常糟糕，最終的往往是團隊的整體績效不高车海，團隊成員的成長很慢笛园，而自己卻很累。

古人說：“用人不疑侍芝，疑人不用研铆。”這句話并非“放之四海而皆準”州叠。在古代棵红，受限于通信技術，反饋延遲顯著咧栗，而且信息在傳遞過程中有大量噪音逆甜，變形嚴重虱肄。在這種情況下，如果根據短期內收集的少量變形的信息做快速決斷交煞，容易陷于草率咏窿。在公司里，這句話用于選人環(huán)節(jié)更為恰當素征，應該改為：錄用不疑集嵌，疑人不錄。

考慮到招聘成本御毅，就算是在錄用層面根欧，有時候也無法做到。作為一個小團隊的管理者端蛆，能夠快速準確的獲取團隊成員的各種反饋信息凤粗，完全不需要“用人不疑，疑人不用”欺税。用人的真正理論基礎來自于“探索和利用”(Exploration and Exploitation )侈沪。不能因為下屬能做什么就只讓他做什么，更不能因為下屬一次失敗就不給機會晚凿。

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

• 首選選擇相信，在面臨失敗后歼秽，收縮信任度应役。

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

• 總是給下屬機會，在恰當地時機給下屬更高的挑戰(zhàn)肆氓。 總之袍祖，蒼天大樹來自一顆小種子，要相信成長的力量谢揪。

效率蕉陋、效率、效率

經巢Ψ觯看到有些同學給自己的績效評分是100分——滿分凳鬓，原因是在過去一段時間太辛苦了，但最終的績效卻一般般患民。天道酬勤不錯缩举，但是天道更酬巧。工程師們都學過數據結構，不同算法的時間復雜度的差距仅孩，僅僅通過更長的工作時間是難以彌補的托猩。為了提升工作學習效率，我們需要注意以下幾點：

• 主要關注效率提升杠氢。很多時候站刑，與效率提升所帶來的收益相比，延長時間所帶來的成果往往不值得一提鼻百。

• 要有清晰的結果導向思維。功勞和苦勞不是一回事摆尝。

• 做正確的事情温艇，而不僅僅正確地做事情。這是一個被不斷提起的話題堕汞，但是錯誤每天都上演勺爱。為了在規(guī)定的時間內完成一個大項目，總是要有所取舍讯检。如果沒有重點琐鲁，均勻發(fā)力，容易事倍功半人灼。如果“南轅北轍”围段，更是可悲可嘆。

架構師能力模型

前面我們已經講完了原則和一些困惑投放，那么工程師到底應該怎么提升自己呢奈泪？

成為優(yōu)秀的架構師是大部分初中級工程師的階段性目標。優(yōu)秀的架構師往往具備七種核心能力：編程能力灸芳、調試能力涝桅、編譯部署能力、性能優(yōu)化能力烙样、業(yè)務架構能力冯遂、在線運維能力、項目管理能力和規(guī)劃能力谒获。

這幾種能力之間的關系大概如下圖蛤肌。編程能力、調試能力和編譯部署能力屬于最基礎的能力究反。不能精通掌握這三種能力寻定，很難在性能優(yōu)化能力和業(yè)務架構能力方面有所成就。具備了一定的性能優(yōu)化能力和業(yè)務架構能力之后精耐，才能在線運維能力和項目管理能力方面表現優(yōu)越狼速。團隊管理能力是最高能力，它對項目管理能力的依賴度更大卦停。

架構師能力模型

編程能力

對工程師而言向胡，編程是最基礎的能力恼蓬，必備技能。其本質是一個翻譯能力僵芹，將業(yè)務需求翻譯成機器能懂的語言处硬。

提升編程能力的書籍有很多。精通面向對象和設計模式是高效編程的基礎拇派。初級工程師應該多寫代碼荷辕、多看代碼。找高手做Code Review件豌，也是提升編程水平的捷徑疮方。

調試能力

程序代碼是系統(tǒng)的靜態(tài)形式，調試的目的是通過查看程序的運行時狀態(tài)來驗證和優(yōu)化系統(tǒng)茧彤。本質上講骡显，工程師們通過不斷調試可以持續(xù)強化其通過靜態(tài)代碼去預測運行狀態(tài)的能力。所以調試能力也是工程師編程能力提升的關鍵手段曾掂。很早之前有個傳說：“調試能力有多強惫谤，編程能力就有多強≈橄矗”不過現在很多編輯器的功能很強大溜歪，調試能力的門檻已經大大降低。

調試能力是項目能否按時险污、高質量提交的關鍵痹愚。即使一個稍具復雜度的項目，大部分工程師也無法一次性準確無誤的完成蛔糯。大項目都是通過不斷地調試進行優(yōu)化和糾錯的拯腮。所以調試能力是不可或缺的能力。

多寫程序蚁飒，解決Bug动壤，多請教高手是提升調試能力的重要手段。

編譯部署能力

編譯并在線上部署運行程序是系統(tǒng)上線的最后一個環(huán)節(jié)淮逻。隨著SOA架構的普及以及業(yè)務復雜度的增加琼懊，大部分系統(tǒng)只是一個完整業(yè)務的一個環(huán)節(jié)，因此爬早，本地編譯和運行并不能完全模擬系統(tǒng)在線運行哼丈。為了快速驗證所編寫程序的正確性，編譯并在線上部署就成了必要環(huán)節(jié)筛严。所以編譯部署能力是一個必備技能醉旦。

讓盤根錯節(jié)的眾多子系統(tǒng)運行起來是個不小的挑戰(zhàn)。得益于SOA架構的普及以及大量編譯、部署工具的發(fā)展车胡，編譯部署的門檻已經大大降低檬输。基于應用層進行開發(fā)的公司匈棘，已經很少有“編譯工程師”的角色了丧慈。但是對于初級工程師而言，編譯部署仍然不是一個輕松的事情主卫。

性能優(yōu)化能力

衡量一個系統(tǒng)成功的一個重要指標是使用量逃默。隨著使用量的增加和業(yè)務復雜度的增加，大部分系統(tǒng)最終都會碰到性能問題队秩。 性能優(yōu)化能力是一個綜合能力笑旺。因為：

• 影響系統(tǒng)性能的因素眾多，包括：數據結構馍资、操作系統(tǒng)、虛擬機关噪、CPU鸟蟹、存儲、網絡等使兔。為了對系統(tǒng)性能進行調優(yōu)建钥，架構師需要掌握所有相關的技術。

• 精通性能優(yōu)化意味著深刻理解可用性虐沥、可靠性熊经、一致性、可維護性欲险、可擴展性等的本質镐依。

• 性能優(yōu)化與業(yè)務強耦合，最終所采取的手段是往往折衷的結果天试。所以槐壳，性能優(yōu)化要深諳妥協(xié)的藝術。

可以說喜每，性能優(yōu)化能力是工程師們成長過程中各種技能開始融會貫通的一個標志务唐。這方面可以參考之前的博客文章“常見性能優(yōu)化策略的總結”。市場上還有很多與性能優(yōu)化相關的書籍带兜，大家可以參考枫笛。多多閱讀開源框架中關于性能優(yōu)化方面的文檔和代碼也不失為好的提升手段。動手解決線上性能問題也是提升性能優(yōu)化能力的關鍵刚照。如果有機會刑巧，跟著高手學習，分析性能優(yōu)化解決方案案例（我們技術博客之前也發(fā)表了很多這方面的文章），也是快速提升性能優(yōu)化能力的手段海诲。

在線運維能力

如果說性能優(yōu)化能力體現的是架構師的靜態(tài)思考能力繁莹，在線運維能力考驗的就是動態(tài)反應能力。殘酷的現實是特幔，無論程序多么完美咨演，Bug永遠存在。與此同時蚯斯，職位越高薄风、責任越大，很多架構師需要負責非常重要的在線系統(tǒng)拍嵌。對于線上故障遭赂，如果不能提前預防以及快速解決，損失可能不堪設想横辆，所以在線運維能力是優(yōu)秀架構師的必備技能撇他。

為了對線上故障進行快速處理，標準化的監(jiān)控狈蚤、上報困肩、升級，以及基本應對機制當然很重要脆侮。通過所觀察到的現象锌畸，快速定位、緩解以及解決相關癥狀也相當關鍵靖避。這要求架構師對故障系統(tǒng)的業(yè)務潭枣、技術具備通盤解讀能力。解決線上故障的架構師就好比一個在參加比賽F1的車手幻捏。賽車手必須要了解自身盆犁、賽車、對手粘咖、同伴蚣抗、天氣、場地等所有因素瓮下，快速決策粒督，不斷調整嚣艇。架構師必須要了解所有技術細節(jié)浓镜、業(yè)務細節(jié)蜕企、處理規(guī)范、同伴等眾多因素路呜，快速決斷迷捧，迅速調整织咧。

在線運維本質上是一個強化學習的過程。很多能力都可以通過看書漠秋、查資料來完成笙蒙，但在線運維能力往往需要大量的實踐來提升。

業(yè)務架構能力

工程師抱怨產品經理的故事屢見不鮮庆锦，抱怨最多的主要原因來自于需求的頻繁變更捅位。需求變更主要有兩個來源：第一個原因是市場改變或戰(zhàn)略調整，第二個原因是偽需求搂抒。對于第一個原因艇搀，無論是工程師還是產品經理，都只能無奈的接受求晶。優(yōu)秀的架構師應該具備減少第二種原因所導致的需求變更的概率焰雕。

偽需求的產生有兩個原因：

第一個原因是需求傳遞變形。從信息論的角度來講芳杏，任何溝通都是一個編碼和解碼的過程矩屁。典型的需求從需求方到產品經理，最終到開發(fā)工程師爵赵，最少需要經歷三次編碼和解碼過程档插。而信息的每一次傳遞都存在一些損失并帶來一些噪音，這導致有些時候開發(fā)出來的產品完全對不上需求亚再。此外，需求方和產品經理在需求可行性晨抡、系統(tǒng)可靠性氛悬，開發(fā)成本控制方面的把控比較弱，也會導致需求變形耘柱。

第二個原因就是需求方完全沒有想好自己的需求如捅。

優(yōu)秀的架構師應該具備辨別真?zhèn)涡枨蟮哪芰Α摶〞r間去了解客戶的真實業(yè)務場景调煎，具備較強的業(yè)務抽象能力镜遣，洞悉客戶的真實需求。系統(tǒng)的真正實施方是工程師士袄，在明確客戶真實需求后悲关，高明的架構師應該具備準確判斷項目對可行性、可靠性娄柳、可用性等方面的要求寓辱，并能具備成本意識。最后赤拒，由于需求與在線系統(tǒng)的緊耦合關系秫筏，掌握在線系統(tǒng)的各種細節(jié)也是成功的業(yè)務架構的關鍵诱鞠。隨著級別的提升，工程師所面對的需求會越來越抽象这敬。承接抽象需求航夺，提供抽象架構是架構師走向卓越的必經之途。

市場上有一些關于如何成為架構師的書崔涂，大家可以參考阳掐。但是架構能力的提升，實踐可能是更重要的方式堪伍。業(yè)務架構師應該關注客戶的痛點而不是PRD文檔锚烦，應該深入關注真實業(yè)務。掌握現存系統(tǒng)的大量技術和業(yè)務細節(jié)也是業(yè)務架構師的必備知識帝雇。

項目管理能力

作為工業(yè)時代的產物涮俄，分工合作融入在互聯(lián)網項目基因里面。架構師也需要負責幾個重大項目才能給自己正名尸闸。以架構師角色去管理項目彻亲，業(yè)務架構能力當然是必備技能。此外吮廉，人員管理和成本控制意識也非常重要苞尝。

項目管理還意味著要有一個大心臟。重大項目涉及技術攻關宦芦、人員變動宙址、需求更改等眾多可變因素。面臨各種變化调卑，還要在確保目標順利達成抡砂，需要較強的抗壓能力。

人員管理需要注意的方面包括：知人善用恬涧，優(yōu)化關系注益，簡化溝通，堅持真理溯捆。

• 知人善用意味著架構師需要了解每個參與者的硬技能和軟素質丑搔。同時，關注團隊成員在項目過程中的表現提揍，按能分配啤月。

• 優(yōu)化關系意味著管理團隊的情緒，畢竟項目的核心是團隊碳锈，有士氣的團隊才能高效達成目標顽冶。

• 簡化溝通意味著快速決策，該妥協(xié)的時候妥協(xié)售碳，權責分明强重。

• 堅持真理意味著頂住壓力绞呈，在原則性問題上絕不退步。

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

• 以終為始佃声、確定里程碑。為了達成目標倘要，所有的計劃必須以終為始來制定圾亏。將大項目分解成幾個小階段，控制每個階段的里程碑可以大大降低項目失敗的風險封拧。

• 把控關鍵路徑和關鍵項目志鹃。按照關鍵路徑管理理論（CPM）的要求，架構師需要確定每個子項目的關鍵路徑泽西，確定其最早和最晚啟動時間曹铃。同時，架構師需要關注那些可能會導致項目整體延期的關鍵節(jié)點捧杉，并集中力量攻破陕见。

• 掌控團隊成員的張弛度。大項目持續(xù)時間會比較長味抖，也包含不同工種评甜。項目實施是一個不斷變化的動態(tài)過程，在這個過程中不是整個周期都很緊張仔涩，不是所有的工種都一樣忙忍坷。優(yōu)秀的架構師必須要具備精細閱讀整體項目以及快速反應和實時調整的能力。這不僅僅可以大大降低項目成本熔脂，還可以提高產出質量和團隊滿意度承匣。總體來說锤悄，“前緊后松”是項目管理的一個重要原則。

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

團隊管理能力

不想做CTO的工程師不是一個好的架構師隶症。走向技術管理應該是工程師的一個主流職業(yè)規(guī)劃。團隊管理的一個核心能力就是規(guī)劃能力岗宣，這包括項目規(guī)劃和人員規(guī)劃蚂会。良好的規(guī)劃需要遵循如下原則：

• 規(guī)劃是利益的博弈。良好的規(guī)劃上面對得起老板耗式，中間對得起自己胁住，下面對得起團隊趁猴。在三者利益者尋找平衡點，實現多方共贏考驗著管理者的智慧和精細拿捏的能力彪见。

• 任何規(guī)劃都比沒有規(guī)劃好儡司。沒有規(guī)劃的團隊就是沒頭的蒼蠅，不符合所有人的利益余指。

• 規(guī)劃不是本本主義捕犬。市場在變，團隊在變酵镜，規(guī)劃也不應該一成不變碉碉。

• 客戶至上的是項目規(guī)劃的出發(fā)點。

• 就人員規(guī)劃而言淮韭，規(guī)劃需要考量團隊成員的能力垢粮、績效、成長等多方面的因素缸濒。

市場上有很多規(guī)劃管理方面的書籍足丢，值得閱讀。最優(yōu)化理論雖然是技術書籍庇配，但它是規(guī)劃的理論基礎斩跌，所以不妨多看看翻閱一下。從自我規(guī)劃開始捞慌，多多學習別人的規(guī)劃也是規(guī)劃能力提升的重要手段耀鸦。

總結

因為受邀去做一個關于“一邊工作，一邊學習”的分享啸澡，作者花了一段時間去思考和匯總學習方法論袖订，接著每天不斷地采集謠言并嘗試解惑，再根據個人經驗繪制出優(yōu)秀架構師的能力模型嗅虏，最后匯集成文洛姑。

文章系統(tǒng)性地闡述了學習原則、分析了常見困惑皮服，并制定明確學習目標楞艾，期望對工程師們的工作學習有所幫助。需要申明的是龄广，文章內容掛一漏萬硫眯，所謂的架構師能力模型也是作者的個人觀點。歡迎大家在評論中分享自己在學習成長方面的心得择同。