35歲是程式員工作的終點？扯淡！

文章原作者: 美團Android專家, 作者: 劉丁

文章連結如下: https://www.jianshu.com/p/600edf410908

引言

古人雲：“活到老，學到老。”網際網路算是最辛苦的行業之一，“加班”對工程師來說已是“家常便飯”，同時網際網路技術又日新月異，很多工程師都疲于應付，叫苦不堪。以至于長期以來流傳一個很廣的誤解：

35歲是程式員工作的終點。

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

• 第一部分闡述了一些學習的原則。任何時候，遵循一些經過檢驗的原則，都是影響效率的重要因素，正确的方法是成功的秘訣。
• 提升工作和學習效率的另一個重要因素是釋惑和良好心态。第二部分分析了我在工作中碰到和看到的一些典型困惑。
• 成為優秀的架構師是大部分國中級工程師的階段性目标。第三部分剖析架構師的能力模型，讓大家對目标所需能力有一個比較清晰的認知。

如何學習

在繁忙的工作中，持之以恒、不斷學習和進步是一件艱巨的任務，需要堅強的毅力和堅定的決心。如果方法不得當，更是事倍功半。幸好我們的古人和現在哲人已經總結了很多優秀的學習方法論，這裡彙總了一些重要原則。遵循這些方法必會對大家的工作學習大有裨益。

貴在堅持

有報道指出，過去幾十年的知識量超過之前人類幾千年的知識量總和。而計算機領域絕對是當代知識更新最快的領域之一，是以，工程師必須要接受這樣一個現實，現在所掌握的深厚知識體系很快就會被淘汰。要想在計算機領域持續做優秀架構師，就必須不停的學習，掌握最新技術。總之，學不可以已。

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

雖然知識更新很快，但是基礎理論的變化卻非常緩慢。這就是“道”和“象”關系，縱是世間萬象，道卻萬變不離其宗。對于那些非常基礎的理論知識，我們需要經常複習，也就是“學而時習之”。

重視實踐

古人雲：“紙上得來終覺淺，絕知此事要躬行。” 學習領域有所謂721模型：個人的成長70%來自于崗位實踐，20%來自向他人學習，10%來自于教育訓練。雖然這種理論存在争議，但對于工程師們來說，按照實踐、學習和教育訓練的方式進行重要性排序，大緻是不錯的。是以重視實踐，在實踐中成長是最重要的學習原則。

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

書本知識主要是傳道——講述抽象原型，而對其具體應用場景的講述往往含糊其辭，對抽象原型之間的關系也是淺嘗辄止。采用同樣精确的語言去描述應用場景和關聯關系将會失去重點，讓人摸不着頭腦。是以，僅僅通過看書來獲得成長就像是用一條腿走路。

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

重視交流

牛頓說：“如果說我看得比别人遠一些，那是因為我站在巨人的肩膀上。”我們需要從别人身上學習。從老師、上司、同僚、下屬甚至對手身上學習，是快速成長的重要手段。

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

此外，在項目中積極參與具體方案讨論也非常重要。參與者先驗感覺了相關背景，并且讨論的觀點和建議也是綜合了發言者多種知識和技能。是以，讨論讓參與者能夠非常全面，立體地了解書本知識。同時，和高手讨論，他們的觀點就會像修剪機剪樹枝一樣，快速的剪掉自己知識領域裡面的疑惑點。

重視總結和輸出

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

将經驗輸出，接受别人的檢驗是高層次的總結。這種輸出不僅幫助了别人，對自身更是大有裨益。總結的方式有很多，包括組織分享，撰寫技術文章等等。當然“日三省吾身”也是不錯的總結方式。總之，多多總結，多多分享，善莫大焉！

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

重視規劃

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

長期規劃

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

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

短期規劃

良好的短期規劃應該在生活、成長、績效和晉升之間取得平衡。大部分公司都會制定一個考核周期——少則一個月，多則一年。是以不妨以考核周期作為短期學習規劃周期。本質上，規劃是一個多目标優化問題，它有一系列的理論方案，這裡不一一細說。基于相關理論，我給出一個簡單易行的方案：

• 确定目标優先級。比如：成長、生活、績效。
• 确定每個目标的下限。從優化理論的角度來看，這被稱為限制。比如績效必須在一般以上，之前已經規劃好的旅行不能更改，必須讀完《Android開發藝術探索》等等。
• 優先為下限目标配置設定足夠的資源。比如，事先規劃好的旅行需要10天，這10天就必須預算出去。
• 按照各主目标的順序依次配置設定資源。比如，最終配置設定給學習的時間是10天。
• 在給定的學習預算下，制定學習目标，要激進。然後給出執行方案。比如，學習目标是掌握基本的統計學知識，并成為 Android專家。具體方案為：完成《Android進階之光》、《Android開發藝術探索》、《Android源碼設計模式》、《Android架構揭秘》四本書的閱讀。
• 對規劃中的各學習任務按目标優先級進行排序，并最先啟動優先級最高的任務。比如，最高優先級是掌握Gradle知識，那麼就要先看實戰Gradle。

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

• 最低目标必須能夠輕松達成的目标，否則，從優化理論的角度來講，該命題無解。比如，類似“半年内完成晉級兩次、績效全部S、從菜鳥成為Java專家”就不太合适作為最低目标。總之，要區分理想和夢想。
• 主要目标規劃必須具備一定的挑戰性，需要規劃出不可能完成的目标。過度規劃本質上是一種貪婪算法，目的是目标價值最大化。因為一切皆有變數，如果其他目标能夠提前完成，就不妨利用這些時間去完成更多的學習目标。總之，前途必須光明，道路必須坎坷。
• 各目标之間不一定共享資源，規劃不一定互有沖突。

此外，短期規劃還可以從如下幾個方面進行優化：

• 學習計劃最好能結合工作計劃，理論聯系實際結合，快速學以緻用。比如，本季度規劃去做一些資料分析工作，那麼不妨把學習目标設定為學習統計知識。
• 要靈活對待規劃的目标和具體執行步驟，需要避免“鄭人買履”式的笑話。面臨新的挑戰和變化，規劃需要不斷地調整。

那些令人糾結的困惑

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

接下來我将總結自己在工作中碰到和看到的一些典型困惑。這些困惑或者長期困擾作者本人，或者困擾我身邊的同僚和朋友。當這些困惑被釋然之後，大家都感覺如重獲釋，為下一階段的征程提供滿滿的正能量。人生就像一場旅途，不必在乎目的地，在乎的，應該是沿途的風景，以及看風景的心情。良好的心态是技術之旅最好的伴侶。期望通過這個解惑之旅，讓大家擁有一個愉快的心情去感受漫長的學習旅途。

學無止境嗎

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

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

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

“一緻性”算得上是計算機領域裡面最經典的難題，它是所有分布式系統的基礎，從多核多CPU到多線程，從跨機器到跨機房，無所不在，幾乎所有的計算機從業人員都在解決這個問題，但是Paxos給出了一個很優雅的解決方案。

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

另外，技術學習是一場對抗賽，雖然學無止境，超越大部分對手就是一種勝利。是以，以正确的學習方式，長時間投入就會形成核心競争力。

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

緻力于在技術上有所成就的工程師，都夢想有朝一日成為技術高手。但技術高手的标準卻存在很大的争議。這是一個有着悠久曆史的誤解：以某種技術的掌握作為技術高手的評判标準。我經常碰到這樣一些情景：因為掌握了某些技術，比如性能優化、NDK、Flutter等，一些工程師就自封為高手。有些工程師非常仰慕别的團隊，原因竟是那個團隊使用了某種技術。

這種誤解的産生有幾個原因：首先，技多不壓身，技術自然是掌握的越多越好，掌握很多技術的人自然不是菜鳥。其次，在網際網路時代來臨之前，資訊擷取是非常昂貴的事情。這就導緻一項技能的掌握可以給個人甚至整個公司帶來優勢地位。網際網路時代，各種架構的出現以及開源的普及快速淘汰或者降低了很多技能的價值，同時降低了很多技術的學習門檻。是以，在目前，掌握某項技能知識隻能是一個短期目标。懷揣某些技能就沾沾自喜的人需要記住：驕傲使人退步。

所謂麻雀雖小，五髒俱全。如果讓你來做造物主，設計麻雀和設計大象的複雜度并沒有明顯差別。一個看起來很小的業務需求，為了達到極緻，所需要的技術和能力是非常綜合和高深的。真正的高手不是拿着所掌握的技術去卡客戶需求，而是傾聽客戶的需求，給出精益求精的方案。完成客戶的需求是一場擂台賽，真正的高手，是會見招拆招的。

不做項目就無法成長嗎

在項目中學習是最快的成長方式之一，很多工程師非常享受這個過程。但是一年到頭都做項目，你可能是在一家外包公司。對于一個做産品的公司，如果年頭到年尾都在做項目，要不然就是在初步創業階段，要不然就是做了大量失敗的項目，總之不算是特别理想的狀态。正常情況，在項目之間都會有一些非項目時間。在這段時間，有些同學會産生迷茫，成長很慢。

項目真的是越多越好嗎？答案顯然是否定的。重複的項目不會給工程師們帶來新的成長。不停的做項目，進而缺乏學習新知識的時間，會導緻“做而不學則殆”。真正讓工程師出類拔萃的是項目的深度，而不是不停地做項目。是以，在項目之間的空檔期，工程師們應該珍惜難得的喘息之機，深入思考，把項目做深，做精。

如何提高項目的深度呢？一般而言，任何項目都有一個目标，當項目完成後，目标就算基本達成了。但是，客戶真的滿意了嗎？系統的可用性、可靠性、可擴充性、可維護性已經做到極緻了嗎？這幾個問題的答案永遠是否定的。是以，任何一個有價值的項目，都可以一直深挖。深挖項目，深度思考還可以鍛煉工程師的創造力。期望不停地做項目的人，就像一個緻力于訓練更多千裡馬的人是發明不出汽車的。鍛煉創造力也不是一蹴而就的事情，需要長時間地思考。總之，工程師們應該總是覺得時間不夠用，畢竟時間是最寶貴的資源。

職責真的很小嗎

很多時候，一個工程師所負責系統的數量和團隊規模與其“江湖地位”正相關。但是，江湖地位與技術成長沒有必然關聯。提升技術能力的關鍵是項目深度以及客戶的挑剔程度。項目越多，在單個項目中投入的時間就越少，容易陷入膚淺。特别需要避免的是“ 在其位不謀其政”的情況。團隊越大，在管理方面需要投入的精力就越多。在管理技巧不成熟，技術眼界不夠高的前提強行負責大團隊，可能會導緻個人疲于應付，團隊毫無建樹。最終“ 一将無能，累死三軍”，效果可能适得其反。

從技術發展的角度來說，技術管理者應該關注自己所能把控的活躍項目的數量，并緻力于提高活躍項目的影響力和技術深度。團隊人數要與個人管理能力、規劃能力和需求把控能力相适應。一份工作讓多個人來幹，每個人的成長都受限。每個人都做簡單重複的工作，對技術成長沒有任何好處。團隊管理和項目管理需要循序漸進，忌“拔苗助長”。

一定要當老大嗎

有一些工程師的人生理想是做團隊裡的技術老大，這當然是一個值得稱贊的理想。可是，如果整個團隊技術能力一般，發展潛力一般，而你是技術最強者，這與其說是幸運，不如說是悲哀。這種場景被稱之為“武大郎開店”。團隊裡的技術頂尖高手不是不能做，但為了能夠持續成長，需要滿足如下幾個條件：

• 首先你得是行業裡面的頂尖專家了——實在很難找到比你更強的人了！
• 其次，你經常需要承擔對你自己的能力有挑戰的任務，但同時你擁有一批聰明能幹的隊友。雖然你的技術能力最高，但是在你不熟悉的領域，你的隊友能夠進行探索并擴充整個團隊的知識。
• 最後，你必須要敏而好學，不恥下問。

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

平台化的傳說

平台化算得上是“高大上”的代名詞了，很多工程師擠破頭就為了和“平台化”沾點邊。然而和其他業務需求相比，平台化需求并沒有本質上的差別。無論是平台化需求還是普通業務需求，它的價值都來自于客戶價值。不同點如下：

• 很多平台化需求的客戶來自于技術團隊，普通需求的客戶來自于業務方。
• 産品經理不同。普通業務需求來自于産品經理，平台化需求的産品經理可能就是工程師自己。長期被産品經理“壓迫”的工程師們，在平台化上終于找到“翻身農奴把歌唱”的感覺。
• 很多平台化的關注點是接入能力和可擴充性，而普通業務的關注點更多。

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

• 平台化絕對不是諸如“統一”、“全面”之類形容詞的堆砌。是否需要平台化，應該綜合考慮：客戶數量，為客戶解決的問題，以及客戶價值是否值得平台化的投入。
• 平台化不是你做平台，讓客戶來服務你。一些平台化設計者的規劃設計裡面，把大量的平台接入工作、髒活累活交給了客戶，然後自己專注于所謂“最高大上”的功能。恰恰相反，平台化應該是客戶什麼都不做，所有的髒活累活都由平台方來做。本質上講，平台化的價值來自于技術深度。真正展現技術深度的恰恰是設計者能夠很輕松的把所有的髒活累活搞定。

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

搞基礎技術就一定很牛嗎

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

比如下面這個流傳很久的段子：越進階的語言就越沒有技術含量。但真是這樣嗎，就拿Java和C來說，這是完全不同的兩種語言，所需要的技能完全不同。C或許跟作業系統更加接近一點，和CPU、記憶體打交道的機會更多一點。但是為了用好Java，程式員在面向對象、設計模式、架構技術方面必須要非常精通。Java工程師轉到C方向确實不容易，但作者也見過很多轉到Java語言的C工程師水土不服。

基礎技術和業務應用技術必然會有不同的關注點，沒有高低之分。之是以産生這種誤解，有兩個原因：

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

對比下來，業務技術和基礎技術各有千秋。但真正的高手關注的是解決問題，所有的技術都是技能而已。

可行性調研的那些坑

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

• 把可行性調研做成不可行性調研。這真的非常糟糕。不可行性的結論往往是：因為這樣或者那樣的原因，是以不可行。
• 避免“老鼠給貓挂鈴铛”式的高風險可行性方案。“天下大事必作于細”，可行性調研一定要細緻入微，避免粗枝大葉。
• 避免調研時間過長。如果發現調研進展進入到指數級複雜度，也就是每前進一步需要之前兩倍的時間投入，就應該果斷的停止調研。

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

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

工程師天生不善溝通嗎

實際工作中，溝通所導緻的問題層出不窮。工程師有不少是比較内向的，總是被貼上“不善溝通”的标簽。實際上，溝通能力是工程師最重要的能力之一，良好的溝通是高效工作學習的基礎，也是通過學習可以掌握的。下面我按工程師的語言說說溝通方面的經驗。

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

• 經常聽到的這樣的争論。一方說：“我已經告訴他了”，另一方說：“我不知道這個事情呀”。把UDP模式被當作TCP模式來使用容易産生扯皮。
• 過度溝通。有些同學對溝通的可靠性産生了過度焦慮，不斷的重複讨論已有結論問題。把TCP模式當成UDP來使用，效率會比較低。

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

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

有效溝通的一個重要原則是提前溝通。溝通本質是資訊交流和處理，可以把被溝通對象形象地比喻成串行資訊處理的CPU。提前溝通，意味着将處理請求盡早放入處理隊列裡面。下面的例子讓很多工程師深惡痛絕：一個需求策劃了1個月，産品設計了2周。當開發工程師第一次聽說該需求的時候，發現開發的時間是2天。工程師據理力争，加班加點1周搞定。最後的結論是工程師非常不給力，不配合。就像工程師讨厭類似需求一樣。要協調一個大項目，希望獲得别人的配合，也需要盡早溝通。

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

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

帶人之道

有些初為導師的工程師由于擔心畢業生的能力太弱，安排任務時候諄諄教誨，最後感覺還是有所顧慮，幹脆自己寫代碼。同樣的事情發生在很多剛剛管理小團隊的工程師身上。最終的結果他們：寫完所有的代碼，讓下屬無代碼可寫。“ 事必躬親”當然非常糟糕，最終的往往是團隊的整體績效不高，團隊成員的成長很慢，而自己卻很累。

古人說：“用人不疑，疑人不用。”這句話并非“放之四海而皆準”。在古代，受限于通信技術，回報延遲顯著，而且資訊在傳遞過程中有大量噪音，變形嚴重。在這種情況下，如果根據短期内收集的少量變形的資訊做快速決斷，容易陷于草率。在公司裡，這句話用于選人環節更為恰當，應該改為：錄用不疑，疑人不錄。

考慮到招聘成本，就算是在錄用層面，有時候也無法做到。作為一個小團隊的管理者，能夠快速準确的擷取團隊成員的各種回報資訊，完全不需要“用人不疑，疑人不用”。用人的真正理論基礎來自于“探索和利用”(Exploration and Exploitation )。不能因為下屬能做什麼就隻讓他做什麼，更不能因為下屬一次失敗就不給機會。

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

• 首先選擇相信，在面臨失敗後，收縮信任度。
• 查找失敗的原因，提供改進意見，提升下屬的能力。
• 總是給下屬機會，在恰當的時機給下屬更高的挑戰。總之，蒼天大樹來自一顆小種子，要相信成長的力量。

效率、效率、效率

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

• 主要關注效率提升。很多時候，與效率提升所帶來的收益相比，延長時間所帶來的成果往往不值得一提。
• 要有清晰的結果導向思維。功勞和苦勞不是一回事。
• 做正确的事情，而不僅僅正确地做事情。這是一個被不斷提起的話題，但是錯誤每天都上演。為了在規定的時間内完成一個大項目，總是要有所取舍。如果沒有重點，均勻發力，容易事倍功半。如果“南轅北轍”，更是可悲可歎。

架構師能力模型

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

成為優秀的架構師是大部分國中級工程師的階段性目标。優秀的架構師往往具備七種核心能力：程式設計能力、調試能力、編譯部署能力、性能優化能力、業務架構能力、線上運維能力、項目管理能力和規劃能力。

這幾種能力之間的關系大概如下圖。程式設計能力、調試能力和編譯部署能力屬于最基礎的能力。不能精通掌握這三種能力，很難在性能優化能力和業務架構能力方面有所成就。具備了一定的性能優化能力和業務架構能力之後，才能線上運維能力和項目管理能力方面表現優越。團隊管理能力是最高能力，它對項目管理能力的依賴度更大。

程式設計能力

對工程師而言，程式設計是最基礎的能力，必備技能。其本質是一個翻譯能力，将業務需求翻譯成機器能懂的語言。

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

調試能力

程式代碼是系統的靜态形式，調試的目的是通過檢視程式的運作時狀态來驗證和優化系統。本質上講，工程師們通過不斷調試可以持續強化其通過靜态代碼去預測運作狀态的能力。是以調試能力也是工程師程式設計能力提升的關鍵手段。很早之前有個傳說：“調試能力有多強，程式設計能力就有多強。”不過現在很多編輯器的功能很強大，調試能力的門檻已經大大降低。

調試能力是項目能否按時、高品質送出的關鍵。即使一個稍具複雜度的項目，大部分工程師也無法一次性準确無誤的完成。大項目都是通過不斷地調試進行優化和糾錯的。是以調試能力是不可或缺的能力。

多寫程式，解決Bug，多請教高手是提升調試能力的重要手段。

編譯部署能力

編譯并線上上部署運作程式是系統上線的最後一個環節。随着SOA架構的普及以及業務複雜度的增加，大部分系統隻是一個完整業務的一個環節，是以，本地編譯和運作并不能完全模拟系統線上運作。為了快速驗證所編寫程式的正确性，編譯并線上上部署就成了必要環節。是以編譯部署能力是一個必備技能。

讓盤根錯節的衆多子系統運作起來是個不小的挑戰。得益于SOA架構的普及以及大量編譯、部署工具的發展，編譯部署的門檻已經大大降低。基于應用層進行開發的公司，已經很少有“編譯工程師”的角色了。但是對于初級工程師而言，編譯部署仍然不是一個輕松的事情。

性能優化能力

衡量一個系統成功的一個重要名額是使用量。随着使用量的增加和業務複雜度的增加，大部分系統最終都會碰到性能問題。性能優化能力是一個綜合能力。因為：

• 影響系統性能的因素衆多，包括：資料結構、作業系統、虛拟機、CPU、存儲、網絡等。為了對系統性能進行調優，架構師需要掌握所有相關的技術。
• 精通性能優化意味着深刻了解可用性、可靠性、一緻性、可維護性、可擴充性等的本質。
• 性能優化與業務強耦合，最終所采取的手段是往往折衷的結果。是以，性能優化要深谙妥協的藝術。

可以說，性能優化能力是工程師們成長過程中各種技能開始融會貫通的一個标志。這方面可以參考之前的部落格文章“常見性能優化政策的總結”。市場上還有很多與性能優化相關的書籍，大家可以參考。多多閱讀開源架構中關于性能優化方面的文檔和代碼也不失為好的提升手段。動手解決線上性能問題也是提升性能優化能力的關鍵。如果有機會，跟着高手學習，分析性能優化解決方案案例（我們技術部落格之前也發表了很多這方面的文章），也是快速提升性能優化能力的手段。

線上運維能力

如果說性能優化能力展現的是架構師的靜态思考能力，線上運維能力考驗的就是動态反應能力。殘酷的現實是，無論程式多麼完美，Bug永遠存在。與此同時，職位越高、責任越大，很多架構師需要負責非常重要的線上系統。對于線上故障，如果不能提前預防以及快速解決，損失可能不堪設想，是以線上運維能力是優秀架構師的必備技能。

為了對線上故障進行快速處理，标準化的監控、上報、更新，以及基本應對機制當然很重要。通過所觀察到的現象，快速定位、緩解以及解決相關症狀也相當關鍵。這要求架構師對故障系統的業務、技術具備通盤解讀能力。解決線上故障的架構師就好比一個在參加比賽F1的車手。賽車手必須要了解自身、賽車、對手、同伴、天氣、場地等所有因素，快速決策，不斷調整。架構師必須要了解所有技術細節、業務細節、處理規範、同伴等衆多因素，快速決斷，迅速調整。

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

業務架構能力

工程師抱怨産品經理的故事屢見不鮮，抱怨最多的主要原因來自于需求的頻繁變更。需求變更主要有兩個來源：第一個原因是市場改變或戰略調整，第二個原因是僞需求。對于第一個原因，無論是工程師還是産品經理，都隻能無奈的接受。優秀的架構師應該具備減少第二種原因所導緻的需求變更的機率。

僞需求的産生有兩個原因：

第一個原因是需求傳遞變形。從資訊論的角度來講，任何溝通都是一個編碼和解碼的過程。典型的需求從需求方到産品經理，最終到開發工程師，最少需要經曆三次編碼和解碼過程。而資訊的每一次傳遞都存在一些損失并帶來一些噪音，這導緻有些時候開發出來的産品完全對不上需求。此外，需求方和産品經理在需求可行性、系統可靠性，開發成本控制方面的把控比較弱，也會導緻需求變形。

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

優秀的架構師應該具備辨識真僞需求的能力。應該花時間去了解客戶的真實業務場景，具備較強的業務抽象能力，洞悉客戶的真實需求。系統的真正實施方是工程師，在明确客戶真實需求後，高明的架構師應該具備準确判斷項目對可行性、可靠性、可用性等方面的要求，并能具備成本意識。最後，由于需求與線上系統的緊耦合關系，掌握線上系統的各種細節也是成功的業務架構的關鍵。随着級别的提升，工程師所面對的需求會越來越抽象。承接抽象需求，提供抽象架構是架構師走向卓越的必經之途。

市場上有一些關于如何成為架構師的書，大家可以參考。但是架構能力的提升，實踐可能是更重要的方式。業務架構師應該關注客戶的痛點而不是PRD文檔，應該深入關注真實業務。掌握現存系統的大量技術和業務細節也是業務架構師的必備知識。

項目管理能力

作為工業時代的産物，分工合作融入在網際網路項目基因裡面。架構師也需要負責幾個重大項目才能給自己正名。以架構師角色去管理項目，業務架構能力當然是必備技能。此外，人員管理和成本控制意識也非常重要。

項目管理還意味着要有一個大心髒。重大項目涉及技術攻關、人員變動、需求更改等衆多可變因素。面臨各種變化，還要在確定目标順利達成，需要較強的抗壓能力。

人員管理需要注意的方面包括：知人善用，優化關系，簡化溝通，堅持真理。

• 知人善用意味着架構師需要了解每個參與者的硬技能和軟素質。同時，關注團隊成員在項目過程中的表現，按能配置設定。
• 優化關系意味着管理團隊的情緒，畢竟項目的核心是團隊，有士氣的團隊才能高效達成目标。
• 簡化溝通意味着快速決策，該妥協的時候妥協，權責分明。
• 堅持真理意味着頂住壓力，在原則性問題上絕不退步。

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

• 以終為始、确定裡程碑。為了達成目标，所有的計劃必須以終為始來制定。将大項目分解成幾個小階段，控制每個階段的裡程碑可以大大降低項目失敗的風險。
• 把控關鍵路徑和關鍵項目。按照關鍵路徑管理理論（CPM）的要求，架構師需要确定每個子項目的關鍵路徑，确定其最早和最晚啟動時間。同時，架構師需要關注那些可能會導緻項目整體延期的關鍵節點，并集中力量攻破。
• 掌控團隊成員的張弛度。大項目持續時間會比較長，也包含不同工種。項目實施是一個不斷變化的動态過程，在這個過程中不是整個周期都很緊張，不是所有的工種都一樣忙。優秀的架構師必須要具備精細閱讀整體項目以及快速反應和實時調整的能力。這不僅僅可以大大降低項目成本，還可以提高産出品質和團隊滿意度。總體來說，“前緊後松”是項目管理的一個重要原則。

項目管理方面的書籍很多。但是，提高業務架構能力同樣重要。積極參與大項目并觀察别人管理項目的方式也是非常重要的提升手段。

團隊管理能力

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

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

市場上有很多規劃管理方面的書籍，值得閱讀。最優化理論雖然是技術書籍，但它是規劃的理論基礎，是以不妨多看看翻閱一下。從自我規劃開始，多多學習别人的規劃也是規劃能力提升的重要手段。

總結

因為受邀去做一個關于“一邊工作，一邊學習”的分享，作者花了一段時間去思考和彙總學習方法論，接着每天不斷地采集謠言并嘗試解惑，再根據個人經驗繪制出優秀架構師的能力模型，最後彙內建文。

文章系統性地闡述了學習原則、分析了常見困惑，并制定明确學習目标，期望對工程師們的工作學習有所幫助。需要申明的是，文章内容挂一漏萬，所謂的架構師能力模型也是作者的個人觀點。歡迎大家在評論中分享自己在學習成長方面的心得。

大家好,我是gaolhjy.

傳統行業轉行的網際網路人。 前期從事Android開發，現技術管理。平時營運微信群"向上而行"(50元付費群)，堅持每天發有價值的資訊,堅持每周至少一篇原創分享。

如果您手頭緊張或介意付費,也可以單純添加我微信。