一樣的工做、一樣的作需求，爲何他們能進阿里

時間 2019-11-30

原文原文鏈接

引言

古人云：「活到老，學到老。」互聯網算是最辛苦的行業之一，「加班」對工程師來講已經是「屢見不鮮」，同時互聯網技術又突飛猛進，不少工程師都疲於應付，叫苦不堪。以致於長期以來流傳一個很廣的誤解：35歲是程序員工做的終點。程序員

如何在繁忙的工做中作好技術積累，構建我的核心競爭力，相信是不少工程師同行都在思考的問題。一樣的工做、一樣的作需求，爲何有的人只能在現有崗位上緩慢前行，而有的人卻能進阿里，本文是我本身的一些總結，試圖從三個方面來解答：算法

第一部分闡述了一些學習的原則。任什麼時候候，遵循一些通過檢驗的原則，都是影響效率的重要因素，正確的方法是成功的祕訣。提高工做和學習效率的另外一個重要因素是釋惑和良好心態。
第二部分分析了我在工做中碰到和看到的一些典型困惑。
成爲優秀的架構師是大部分初中級工程師的階段性目標。第三部分剖析架構師的能力模型，讓你們對目標所需能力有一個比較清晰的認知。

如何學習

在繁忙的工做中，鍥而不捨、不斷學習和進步是一件艱鉅的任務，須要堅強的毅力和堅決的決心。若是方法不得當，更是事倍功半。幸虧咱們的古人和如今哲人已經總結了不少優秀的學習方法論，這裏彙總了一些重要原則。遵循這些方法必會對你們的工做學習大有裨益。編程

貴在堅持

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

所謂「冰凍三尺，非一日之寒，水滴石穿，非一日之功」，通往架構師的道路漫長而又艱鉅，輕易放棄，則全部付出瞬間付之東流。要想成爲優秀的架構師，貴在堅持！性能優化

雖然知識更新很快，可是基礎理論的變化卻很是緩慢。這就是「道」和「象」關係，縱是世間萬象，道卻萬變不離其宗。對於那些很是基礎的理論知識，咱們須要常常複習，也就是「學而時習之」。網絡

重視實踐

古人云：「紙上得來終覺淺，絕知此事要躬行。」學習領域有所謂721模型：我的的成長70%來自於崗位實踐，20%來自向他人學習，10%來自於培訓。雖然這種理論存在爭議，但對於工程師們來講，按照實踐、學習和培訓的方式進行重要性排序，大體是不錯的。因此重視實踐，在實踐中成長是最重要的學習原則。數據結構

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

書本知識主要是傳道——講述抽象原型，而對其具體應用場景的講述每每含糊其辭，對抽象原型之間的關係也是淺嘗輒止。採用一樣精確的語言去描述應用場景和關聯關係將會失去重點，讓人摸不着頭腦。因此，僅僅經過看書來得到成長就像是用一條腿走路。架構

重視實踐，充分運用感性認知潛能，在項目中磨鍊本身，纔是正確的學習之道。在實踐中，在某些關鍵動做上刻意練習，也會取得事半功倍的效果。併發

重視交流

牛頓說：「若是說我看得比別人遠一些，那是由於我站在巨人的肩膀上。」咱們須要從別人身上學習。從老師、領導、同事、下屬甚至對手身上學習，是快速成長的重要手段。

向老師和領導學習已是人們生活習慣的一部分了。可是從同事甚至對手那裏學習也很重要，由於這些人和咱們自身更類似。因此要多多觀察，取其所長，棄其所短。對於團隊的小兄弟和下屬，也要「不恥下問」。

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

重視總結和輸出

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

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

解答別人的問題也是我的成長的重要手段。有時候，某個問題本身原本不太懂，可是在給別人講解的時候卻豁然開朗。因此，「誨人不倦」利人惠己。

重視規劃

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

長期規劃

長期規劃的實施須要毅力和決心，可是作正確的長期規劃還須要高瞻遠矚的眼界、超級敏感的神經和中大獎的運氣。對於大部分人來講，長期規劃定主要是「定方向」。但遵循以下原則可以減小犯方向性錯誤的機率：

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

短時間規劃

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

肯定目標優先級。好比：成長、生活、績效。
肯定每一個目標的下限。從優化理論的角度來看，這被稱爲約束。好比績效必須在通常以上，以前已經規劃好的旅行不能更改，必須讀完《Effective Java》等等。
優先爲下限目標分配足夠的資源。好比，事先規劃好的旅行須要10天，這10天就必須預算出去。
按照各主目標的順序依次分配資源。好比，最終分配給學習的時間是10天。
在給定的學習預算下，制定學習目標，要激進。而後給出執行方案。好比，學習目標是掌握基本的統計學知識，併成爲Java專家。具體方案爲：完成《Effective Java》、《Java Performance》、《Design Pattern》、《Head First Statistics》四本書的閱讀。
對規劃中的各學習任務按目標優先級進行排序，並最早啓動優先級最高的任務。好比，最高優先級是掌握統計理論，那麼就要先看《Head First Statistics》。

對於該方案，要注意如下幾點：

最低目標必須可以輕鬆達成的目標，不然，從優化理論的角度來說，該命題無解。好比，相似「半年內完成晉級兩次、績效所有S、從菜鳥成爲Java專家」就不太合適做爲最低目標。總之，要區分理想和夢想。
主要目標規劃必須具有必定的挑戰性，須要規劃出不可能完成的目標。過分規劃本質上是一種貪婪算法，目的是目標價值最大化。由於一切皆有變數，若是其餘目標可以提早完成，就不妨利用這些時間去完成更多的學習目標。總之，前途必須光明，道路必須坎坷。
各目標之間不必定共享資源，規劃不必定互有衝突。

此外，短時間規劃還能夠從以下幾個方面進行優化：

學習計劃最好能結合工做計劃，理論聯繫實際結合，快速學以至用。好比，本季度規劃去作一些數據分析工做，那麼不妨把學習目標設置爲學習統計知識。
要靈活對待規劃的目標和具體執行步驟，須要避免「鄭人買履」式的笑話。面臨新的挑戰和變化，規劃須要不斷地調整。

那些使人糾結的困惑

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

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

學無止境嗎

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

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

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

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

權限管理是不少工程師的噩夢，但若是你能搞定「Attribute Based Access Control(ABAC)」和「Role-Based Access Control(RBAC)」，也能達到至關高度。

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

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

致力於在技術上有所成就的工程師，都夢想有朝一日成爲技術高手。但技術高手的標準卻存在很大的爭議。這是一個有着悠久歷史的誤解：以某種技術的掌握做爲技術高手的評判標準。我常常碰到這樣一些情景：由於掌握了某些技術，好比Spring、Kafka、Elasticsearch等，一些工程師就自封爲高手。有些工程師很是仰慕別的團隊，緣由竟是那個團隊使用了某種技術。

這種誤解的產生有幾個緣由：首先，技多不壓身，技術天然是掌握的越多越好，掌握不少技術的人天然不是菜鳥。其次，在互聯網時代來臨以前，信息獲取是很是昂貴的事情。這就致使一項技能的掌握能夠給我的甚至整個公司帶來優點地位。互聯網時代，各類框架的出現以及開源的普及快速淘汰或者下降了不少技能的價值，同時下降了不少技術的學習門檻。因此，在當前，掌握某項技能知識只能是一個短時間目標。懷揣某些技能就沾沾自喜的人須要記住：驕傲令人退步。

所謂麻雀雖小，五臟俱全。若是讓你來作造物主，設計麻雀和設計大象的複雜度並無明顯區別。一個看起來很小的業務需求，爲了達到極致，所須要的技術和能力是很是綜合和高深的。真正的高手不是拿着所掌握的技術去卡客戶需求，而是傾聽客戶的需求，給出精益求精的方案。完成客戶的需求是一場擂臺賽，真正的高手，是會見招拆招的。

不作項目就沒法成長嗎

在項目中學習是最快的成長方式之一，不少工程師很是享受這個過程。可是一年到頭都作項目，你多是在一家外包公司。對於一個作產品的公司，若是年頭到年尾都在作項目，要否則就是在初步創業階段，要否則就是作了大量失敗的項目，總之不算是特別理想的狀態。正常狀況，在項目之間都會有一些非項目時間。在這段時間，有些同窗會產生迷茫，成長很慢。

項目真的是越多越好嗎？答案顯然是否認的。重複的項目不會給工程師們帶來新的成長。不停的作項目，從而缺少學習新知識的時間，會致使「作而不學則殆」。真正讓工程師出類拔萃的是項目的深度，而不是不停地作項目。因此，在項目之間的空檔期，工程師們應該珍惜可貴的喘息之機，深刻思考，把項目作深，作精。

如何提升項目的深度呢？通常而言，任何項目都有一個目標，當項目完成後，目標就算基本達成了。可是，客戶真的滿意了嗎？系統的可用性、可靠性、可擴展性、可維護性已經作到極致了嗎？這幾個問題的答案永遠是否認的。因此，任何一個有價值的項目，均可以一直深挖。深挖項目，深度思考還能夠鍛鍊工程師的創造力。指望不停地作項目的人，就像一個致力於訓練更多千里馬的人是發明不出汽車的。鍛鍊創造力也不是一蹴而就的事情，須要長時間地思考。總之，工程師們應該老是以爲時間不夠用，畢竟時間是最寶貴的資源。

職責真的很小嗎

不少時候，一個工程師所負責系統的數量和團隊規模與其「江湖地位」正相關。可是，江湖地位與技術成長沒有必然關聯。提高技術能力的關鍵是項目深度以及客戶的挑剔程度。項目越多，在單個項目中投入的時間就越少，容易陷入膚淺。特別須要避免的是「在其位不謀其政」的狀況。團隊越大，在管理方面須要投入的精力就越多。在管理技巧不成熟，技術眼界不夠高的前提強行負責大團隊，可能會致使我的疲於應付，團隊毫無建樹。最終「一將無能，累死三軍」，效果可能拔苗助長。

從技術發展的角度來講，技術管理者應該關注本身所能把控的活躍項目的數量，並致力於提升活躍項目的影響力和技術深度。團隊人數要與我的管理能力、規劃能力和需求把控能力相適應。一份工做讓多我的來幹，每一個人的成長都受限。每一個人都作簡單重複的工做，對技術成長沒有任何好處。團隊管理和項目管理須要按部就班，忌「適得其反」。

必定要當老大嗎

有一些工程師的人生理想是作團隊裏的技術老大，這固然是一個值得稱讚的理想。但是，若是整個團隊技術能力通常，發展潛力通常，而你是技術最強者，這與其說是幸運，不如說是悲哀。這種場景被稱之爲「武大郎開店」。團隊裏的技術頂尖高手不是不能作，但爲了可以持續成長，須要知足以下幾個條件：

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

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

平臺化的傳說

平臺化算得上是「高大上」的代名詞了，不少工程師擠破頭就爲了和「平臺化」沾點邊。然而和其餘業務需求相比，平臺化需求並無本質上的區別。不管是平臺化需求仍是普通業務需求，它的價值都來自於客戶價值。不一樣點以下：

不少平臺化需求的客戶來自於技術團隊，普通需求的客戶來自於業務方。
產品經理不一樣。普通業務需求來自於產品經理，平臺化需求的產品經理可能就是工程師本身。長期被產品經理「壓迫」的工程師們，在平臺化上終於找到「翻身農奴把歌唱」的感受。
不少平臺化的關注點是接入能力和可擴展性，而普通業務的關注點更多。

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

平臺化絕對不是諸如「統一」、「全面」之類形容詞的堆砌。是否須要平臺化，應該綜合考慮：客戶數量，爲客戶解決的問題，以及客戶價值是否值得平臺化的投入。
平臺化不是你作平臺，讓客戶來服務你。一些平臺化設計者的規劃設計裏面，把大量的平臺接入工做、髒活累活交給了客戶，而後本身專一於所謂「最高大上」的功能。偏偏相反，平臺化應該是客戶什麼都不作，全部的髒活累活都由平臺方來作。本質上講，平臺化的價值來自於技術深度。真正體現技術深度的偏偏是設計者可以很輕鬆的把全部的髒活累活搞定。

因此平臺化的最佳實踐是：投入最少的資源，解決最多的問題。平臺解決一切，客戶不勞而獲。

搞基礎技術就必定很牛嗎

常常聽到同窗們表達對基礎技術部同窗的敬仰之情，而對搞業務技術的同窗表現出很輕視，認爲存儲、消息隊列、服務治理框架（好比美團點評內部使用的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、存儲、網絡等。爲了對系統性能進行調優，架構師須要掌握全部相關的技術。
精通性能優化意味着深入理解可用性、可靠性、一致性、可維護性、可擴展性等的本質。
性能優化與業務強耦合，最終所採起的手段是每每折衷的結果。因此，性能優化要深諳妥協的藝術。

能夠說，性能優化能力是工程師們成長過程當中各類技能開始融會貫通的一個標誌。這方面能夠參考以前的博客文章「常見性能優化策略的總結」。市場上還有不少與性能優化相關的書籍，你們能夠參考。多多閱讀開源框架中關於性能優化方面的文檔和代碼也不失爲好的提高手段。動手解決線上性能問題也是提高性能優化能力的關鍵。若是有機會，跟着高手學習，分析性能優化解決方案案例（我技術博客以前也發表了不少這方面的文章），也是快速提高性能優化能力的手段。

性能優化能力是架構師必須掌握的一種能力，說到這裏也順便給你們推薦一個架構交流學習羣：650385180，裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系。還能領取免費的學習資源，下面的性能優化腦圖也是在羣裏獲取。相信對於已經工做和遇到技術瓶頸的碼友，在這個羣裏必定有你須要的內容。

在線運維能力

若是說性能優化能力體現的是架構師的靜態思考能力，在線運維能力考驗的就是動態反應能力。殘酷的現實是，不管程序多麼完美，Bug永遠存在。與此同時，職位越高、責任越大，不少架構師須要負責很是重要的在線系統。對於線上故障，若是不能提早預防以及快速解決，損失可能不堪設想，因此在線運維能力是優秀架構師的必備技能。

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

在線運維本質上是一個強化學習的過程。不少能力均可以經過看書、查資料來完成，但在線運維能力每每須要大量的實踐來提高。

業務架構能力

工程師抱怨產品經理的故事家常便飯，抱怨最多的主要緣由來自於需求的頻繁變動。需求變動主要有兩個來源：第一個緣由是市場改變或戰略調整，第二個緣由是僞需求。對於第一個緣由，不管是工程師仍是產品經理，都只能無奈的接受。優秀的架構師應該具有減小第二種緣由所致使的需求變動的機率。

僞需求的產生有兩個緣由：

第一個緣由是需求傳遞變形。從信息論的角度來說，任何溝通都是一個編碼和解碼的過程。典型的需求從需求方到產品經理，最終到開發工程師，最少須要經歷三次編碼和解碼過程。而信息的每一次傳遞都存在一些損失並帶來一些噪音，這致使有些時候開發出來的產品徹底對不上需求。此外，需求方和產品經理在需求可行性、系統可靠性，開發成本控制方面的把控比較弱，也會致使需求變形。

第二個緣由就是需求方徹底沒有想好本身的需求。

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

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

項目管理能力

做爲工業時代的產物，分工合做融入在互聯網項目基因裏面。架構師也須要負責幾個重大項目才能給本身正名。以架構師角色去管理項目，業務架構能力固然是必備技能。此外，人員管理和成本控制意識也很是重要。

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

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

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

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

以終爲始、肯定里程碑。爲了達成目標，全部的計劃必須以終爲始來制定。將大項目分解成幾個小階段，控制每一個階段的里程碑能夠大大下降項目失敗的風險。
把控關鍵路徑和關鍵項目。按照關鍵路徑管理理論（CPM）的要求，架構師須要肯定每一個子項目的關鍵路徑，肯定其最先和最晚啓動時間。同時，架構師須要關注那些可能會致使項目總體延期的關鍵節點，並集中力量攻破。
掌控團隊成員的張弛度。大項目持續時間會比較長，也包含不一樣工種。項目實施是一個不斷變化的動態過程，在這個過程當中不是整個週期都很緊張，不是全部的工種都同樣忙。優秀的架構師必需要具有精細閱讀總體項目以及快速反應和實時調整的能力。這不只僅能夠大大下降項目成本，還能夠提升產出質量和團隊滿意度。整體來講，「前緊後鬆」是項目管理的一個重要原則。

項目管理方面的書籍不少。可是，提升業務架構能力一樣重要。積極參與大項目並觀察別人管理項目的方式也是很是重要的提高手段。