iOS工程師如何在工作中提升自己，晉陞架構師，走向人生巔峰？

標籤：結果   統一   鍛煉   肩膀   段子   有一個   設計   開源架構   資料   

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

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

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

作為一個開發人員，有一個學習的氛圍跟一個交流圈子特別重要，這是一個我的iOS交流群：638302184，不管你是小白還是大牛歡迎入駐 ，分享BAT,阿里面試題、面試經驗，討論技術， 大家一起交流學習成長！希望協助開發人員少走彎路。

如何學習

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

貴在堅持

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

所謂“冰凍三尺，非一日之寒，水滴石穿，非一日之功”，通往架構師的道路漫長而又艱巨，輕易放棄，則所有付出瞬間付之東流。要想成為優秀的架構師，貴在堅持！雖然知識更新很快，但是基礎理論的變化卻非常緩慢。這就是“道”和“象”關係，縱是世間永珍，道卻萬變不離其宗。對於那些非常基礎的理論知識，我們需要經常複習，也就是“學而時習之”。

重視實踐

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

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

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

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

重視交流

牛頓說：“如果說我看得比別人遠一些，那是因為我站在巨人的肩膀上。”我們需要從別人身上學習。從老師、領導、同事、下屬甚至對手身上學習，是快速成長的重要手段。向老師和領導學習已經是人們生活習慣的一部分了。但是從同事甚至對手那裡學習也很重要，因為這些人和我們自身更相似。所以要多多觀察，取其所長，棄其所短。對於團隊的小兄弟和下屬，也要“不恥下問”。

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

重視總結和輸出

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

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

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

 

那些令人糾結的困惑

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

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

學無止境嗎

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

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

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

“一致性”算得上是電腦領域裡面最經典的難題，它是所有分布式系統的基礎，從多核多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、儲存、網路等。為了對系統效能進行調優，架構師需要掌握所有相關的技術。

精通效能最佳化意味著深刻理解可用性、可靠性、一致性、可維護性、可擴充性等的本質。

效能最佳化與業務強耦合，最終所採取的手段是往往折衷的結果。所以，效能最佳化要深諳妥協的藝術。

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

線上營運能力

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

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

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

業務架構能力

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

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

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

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

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

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

專案管理能力

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

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

人員管理需要注意的方麵包括：知人善用，最佳化關係，簡化溝通，堅持真理。

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

最佳化關係意味著管理團隊的情緒，畢竟項目的核心是團隊，有士氣的團隊才能高效達成目標。

簡化溝通意味著快速決策，該妥協的時候妥協，權責分明。

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

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

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

把控關鍵路徑和關鍵項目。按照關鍵路徑管理理論（CPM）的要求，架構師需要確定每個子項目的關鍵路徑，確定其最早和最晚啟動時間。同時，架構師需要關注那些可能會導致項目整體延期的關鍵節點，並集中力量攻破。

掌控團隊成員的張弛度。大項目期間會比較長，也包含不同工種。項目實施是一個不斷變化的動態過程，在這個過程中不是整個周期都很緊張，不是所有的工種都一樣忙。優秀的架構師必須要具備精細閱讀整體項目以及快速反應和即時調整的能力。這不僅僅可以大大降低項目成本，還可以提高產出品質和團隊滿意度。總體來說，“前緊後松”是專案管理的一個重要原則。

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

團隊管理能力

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

規劃是利益的博弈。良好的規划上面對得起老闆，中間對得起自己，下面對得起團隊。在三者利益者尋找平衡點，實現多方共贏考驗著管理者的智慧和精細拿捏的能力。

任何規劃都比沒有規劃好。沒有規劃的團隊就是沒頭的蒼蠅，不符合所有人的利益。

規劃不是本本主義。市場在變，團隊在變，規劃也不應該一成不變。

客戶至上的是專案規劃的出發點。

就人員規劃而言，規劃需要考量團隊成員的能力、績效、成長等多方面的因素。

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

總結

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

作為一個開發人員，有一個學習的氛圍跟一個交流圈子特別重要，這是一個我的iOS交流群：638302184，不管你是小白還是大牛歡迎入駐 ，分享BAT,阿里面試題、面試經驗，討論技術， 大家一起交流學習成長！希望協助開發人員少走彎路。

不詳

原文連結：79922326

文章來源於網路，如有侵權，請聯絡小編刪除。

iOS工程師如何在工作中提升自己，晉陞架構師，走向人生巔峰？