簡介

古人說：“活到老，學老。”日新月異，許多工程師不堪重負，抱怨不斷。以至于長期以來一直存在一個普遍的誤解：35 歲是程序員工作的終點。

如何在忙碌的工作中積累技術，打造個人核心競爭力，相信是很多工程師都在思考的問題。這篇文章是我自己的一些總結，試圖從三個方面來回答：

如何學習

在忙碌的工作中，堅持不懈、不斷學習進步是一項艱巨的任務，需要堅強的毅力和堅定的決心。如果方法不對，效果會更差。幸運的是，我們古今的哲學家總結了許多優秀的研究方法，這里有一些重要的原則。遵循這些方法，將對大家的工作和學習大有裨益。

你在堅持

據悉，過去幾十年的知識量超過了前幾千年的知識量。計算機領域絕對是現代知識更新最快的領域之一。因此，工程師必須接受他們現在擁有的深度知識系統很快就會過時的現實。如果你想在計算機領域繼續成為一名優秀的架構師，你必須不斷學習并掌握最新的技術。畢竟是學不來的。

所謂“凍三尺，非一日之寒，一滴水一石，非一日之功”，建筑師之路漫長而艱辛。如果你輕易放棄，你所有的努力都會在瞬間付諸東流。 如果你想成為一名優秀的建筑師，你需要持之以恒！

雖然知識更新很快，但基礎理論變化很慢。這就是“道”與“象”的關系。世間雖有萬象，但道始終如一。對于那些非常基礎的理論知識，我們需要經常復習，也就是“時不時的學習和學習”。

注意練習

古人說：“紙上談兵，淺嘗輒止，無所不知，必練。”學習領域有一個所謂的721模式：個人成長的70%來自于在職實踐，20%來自于向他人學習，10%來自于培訓。盡管這個理論是有爭議的，但工程師通常最好根據實踐、學習和培訓來排列他們的重要性。因此，重視實踐，在實踐中成長是最重要的學習原則。

人類的認知有兩種：感性認知和理性認知。這兩種認知是不可替代的。很大程度上，實踐來自感性學習，而閱讀更像是理性學習。以學開車為例，很難想象有人會通過學習書本知識來開車。

書本知識主要是說教——講抽象原型，而對其具體應用場景的描述往往比較模糊，抽象原型之間的關系也很淺薄。使用相同的精確語言來描述應用場景和關系會失去焦點和混淆。所以，讀書成長就像單腿走路。

正確的學習方式是重視實踐，充分發揮感性認知潛能，在項目中磨練自己。在實踐中，對一些關鍵動作進行刻意練習，也會達到事半功倍的效果。

價值溝通

牛頓說：“如果我比別人看得更遠，那是因為我站在巨人的肩膀上。”我們需要向別人學習。向老師、領導、同事、下屬甚至對手學習，是快速成長的重要手段。

向老師和領導學習已經成為人們生活的一部分。但向同事甚至對手學習也很重要，因為這些人與我們更相似。所以，要多觀察，取其長，舍其短。對于團隊的小兄弟和屬下，也“不恥下問”。

此外，積極參與項目中具體選項的討論非常重要。參與者對相關背景有先驗感知，所討論的想法和建議是演講者多種知識和技能的結合。因此，討論讓參與者以非常全面和立體的方式理解書籍知識。同時與專家討論，他們的意見會像剪枝機一樣，快速斬斷自己知識領域的疑惑。

注意總結和輸出

工程師在實踐中會掌握很多細節，但即使掌握了所有細節，在沒有深入總結和思考的情況下也會陷入“學習思考”。不思則無動于衷”。成長的“量變”來自于對細節的漸進深入的把控，而真正的“質變”來自于對“道”的更深理解.

輸出經驗，接受別人的考驗，是一個高層次的總結。這種輸出不僅對別人有幫助，對自己也有很大的好處。總結的方法有很多，包括組織分享、寫技術文章等等。當然，“一日三餐”也是一個很好的概括方式。總之，多多總結，多多分享，太好了！

回答別人的問題也是個人成長的重要手段。有時候，我對某個問題不太了解，但是當我向別人解釋時，它突然變得清晰了。所以，“教人孜孜不倦”是利人利己。

專注于規劃

對外一切都是成立的，如果沒有伏筆，就會失敗。一個好的計劃是長期學習生涯成功的一半。

長期規劃

長期規劃的實施需要毅力和決心，但做正確的長期規劃也需要遠見、超敏感的神經和中大獎的運氣。對大多數人來說，長遠規劃主要是“定方向”。但是，遵循以下原則可以降低出現方向錯誤的概率：

短期規劃

一個好的短期規劃應該在生活、成長、績效和晉升之間取得平衡。大多數公司都會有一個評估周期——短則一個月，長則一年。因此，建議將評估周期用作短期學習計劃周期。規劃本質上是一個多目標優化問題，有一系列理論解，這里不再詳述。根據相關理論，我給出一個簡單易行的方案：

對于這個計劃，請注意以下幾點：

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

那些糾結的困惑

人生是一場馬拉松，漫漫長路難免有很多迷茫。迷茫就像桎梏讓我們跌跌撞撞，迷茫是讓我們停滯不前的僵局。

接下來，我將總結一些我在工作中遇到和看到的典型困惑。這些困惑一直困擾著作者本人，或者困擾著身邊的同事和朋友。當這些迷惘一掃而空，每個人都仿佛重新得到了釋放，為下一階段的旅程提供了滿滿的正能量。人生就像一場旅行。你不必關心目的地。你在意的應該是沿途的風景和看風景的心情。良好的心態是科技之旅的最佳伴侶。希望通過這次解謎之旅，讓大家有愉快的心情體驗漫長的學習之旅。

學習沒有盡頭嗎？

我們必須承認一個殘酷的現實：人的生命是有限的，但知識是無限的。用有限的生命學習無限的知識是不可能完成的任務。想到這里，一些工程師不禁有些悲觀。如果你做得對并且足夠勤奮，你就不必難過。

雖然，人類的整體知識體系一直在擴展。然而，在許多重要的工程細分領域，基礎理論并不先進。在計算的許多重要領域，工程師都有能力在有限的時間內掌握核心關鍵點。

例如，密碼學被認為是一門非常高級的學科，但是一大類密碼技術是基于數論中一個非常簡單的理論——素數分解：給定兩個素數，很容易計算它們的乘積，但是，給定兩個素數的乘積，分解的計算量驚人。

“一致性”可以說是計算機領域最經典的問題。它是所有分布式系統的基礎，從多核多CPU到多線程，從跨機到跨機房，無處不在，幾乎所有的計算機從業者都在研究這個問題，但Paxos有一個優雅的解決方案。

權限管理是很多工程師的噩夢，但如果你能處理好“基于（ABAC）”和“基于角色（RBAC）”，你可以達到相當高的高度。

另外，技術學習是一場競技游戲，雖然學習無止境，但超越大多數對手是一種勝利。因此，通過正確的學習方法，長期投資將形成核心競爭力。

沒有絕對精湛的技術，只有真正的大師

致力于技術成就的工程師都夢想有朝一日成為技術大師。但對于技術大師的標準卻存在不少爭議。這是一個由來已久的誤解：掌握某項技術是評判技術高手的標準。我經常遇到這樣的情況：有的工程師因為掌握了某種技術，就自稱是專家，比如Kafka等。有的工程師仰望另一個團隊，因為那個團隊使用了某種技術。

造成這種誤解有幾個原因：首先，技能越多，技能越好。掌握很多技巧的人，自然不是菜鳥。其次，在互聯網時代到來之前，獲取信息的成本非常高。這導致掌握一種技能，可以為個人甚至整個公司帶來優勢。互聯網時代，各種框架的出現和開源的普及迅速淘汰或降低了很多技能的價值，同時也降低了很多技術的學習門檻。因此，目前掌握一定的技能知識只能是短期目標。對某些技能自滿的人需要記住：驕傲是讓你退縮的原因。

所謂麻雀雖小，五臟俱全。如果你是創造者，那么設計麻雀和設計大象在復雜性上沒有顯著差異。一個看似很小的業務需求，要想做到極致，所需要的技術和能力都非常全面和先進。真正的主人不是用掌握的技術去滿足客戶的需求，而是傾聽客戶的需求，給出更好的解決方案。滿足客戶需求是一場競技場比賽，真正的高手會出招。

不做項目就不能成長嗎？

在項目中學習是最快的成長方式之一，許多工程師都非常喜歡這個過程。但是全年都在做項目，你可能在一家外包公司。對于一家產品公司來說，如果是從年初到年末都在做項目，或者處于創業初期，或者做過很多失敗的項目，都不是特別理想的狀態。通常，項目之間會有一些非項目時間。在此期間，有些學生會出現迷茫，成長非常緩慢。

更多的項目真的更好嗎？答案顯然是否定的。重復的項目不會給工程師帶來新的增長。不斷地做項目，沒有時間學習新知識，會導致“不學則做”。真正讓工程師出類拔萃的是項目的深度，而不是不間斷的項目。因此，在項目之間的間隙，工程師應該珍惜難得的喘息之機，深入思考，把項目做的更深更好。

如何增加項目的深度？一般來說，任何項目都有一個目標，當項目完成后，目標就基本實現了。但客戶真的滿意嗎？系統的可用性、可靠性、可擴展性和可維護性是否做到了極致？這些問題的答案始終是否定的。因此，對于任何有價值的項目，你總是可以深挖。深入項目，深入思考，也能鍛煉工程師的創造力。一個希望繼續做項目的人，比如一個致力于培訓更多千里馬的人，是無法發明汽車的。發揮創造力不是一朝一夕就能完成的事情。需要很長時間才能思考。總之，工程師應該始終覺得時間是不夠的，畢竟時間是最寶貴的資源。

責任真的很小嗎？

很多時候，工程師負責的系統數量和團隊規模與其“江湖地位”正相關。然而，江湖的地位與技術的成長并不必然相關。提高技術能力的關鍵是項目的深度和客戶的洞察力水平。項目越多，花在單個項目上的時間就越少，很容易陷入膚淺。尤其需要避免的是“在位不當權”的情況。團隊越大it工程師，管理它所花費的精力就越多。在管理技能不成熟、技術眼光不夠高的前提下，強行執掌一個大團隊，可能會導致個人不堪重負，團隊失敗。最后“一將無能，三軍精疲力盡”，效果可能適得其反。

從技術發展的角度，技術管理者要關注自己能控制的活躍項目的數量，致力于提升活躍項目的影響力和技術深度。團隊的規模要與個人的管理能力、計劃能力和需求控制能力相適應。一項工作是由多人完成的，每個人的成長都是有限的。每個人都在做簡單的重復工作，對技術的發展沒有好處。團隊管理和項目管理要循序漸進，切忌“拔苗助長”。

你一定要當老板嗎？

有些工程師的人生理想是成為團隊中的技術負責人，這當然是一個值得稱贊的理想。但是，如果整個團隊的技術能力一般，發展潛力一般，而你是技術最強的，這與其說是幸運，不如說是悲哀。這種場景叫做“武大郎開店”。團隊中頂尖的技術專家做這件事并非不可能，但要想不斷成長，必須滿足以下條件：

否則，加入更強的技術團隊可能是更好的選擇，至少不是什么值得驕傲的事情。

平臺化的傳奇

平臺化是“高大上”的代名詞，很多工程師為了參與“平臺化”而絞盡腦汁。但是，與其他業務需求相比，平臺需求并沒有根本的不同。無論是平臺需求還是普通業務需求，其價值都來自于客戶價值。區別如下：

說到底，平臺化是一個普遍的需求。在實施平臺化之前，必須避免以下兩個誤區：

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

從事基礎技術一定要厲害嗎？

我經常聽到學生對基礎技術系的學生表示欽佩，但對從事商業技術的學生表示鄙視。相信存儲、消息隊列、服務治理框架（如美團點評內部使用的OCTO）等都可以稱為真正的技術。事實并非如此，更基礎的不一定更深刻。

比如下面這段流傳已久的一段話：語言越高級，技術含量越少。但真的是這樣嗎？以Java和C為例，這是兩種完全不同的語言，需要完全不同的技能。 C可能更接近操作系統，有更多機會處理CPU和內存。但是為了用好Java，程序員必須非常精通面向對象、設計模式和框架技術。 Java工程師轉C確實不容易，但是筆者也看到很多C轉Java的工程師不滿意。

基礎技術和業務應用技術難免有不同的關注點，沒有高低之分。造成這種誤解的原因有兩個：

相比之下，業務技術和基礎技術各有優缺點。但真正的高手專注于解決問題，所有技術都是技能。

可行性研究的那些坑

在工作中進行可行性研究時有發生。在進行可行性研究時，應避免以下幾種情況：

可行性研究的結論應該是收益和成本之間的折衷。 p>在實踐中，由溝通引起的問題層出不窮。許多工程師比較內向，總是被貼上“溝通不暢”的標簽。事實上，溝通能力是工程師最重要的能力之一。良好的溝通是高效工作和學習的基礎，也可以通過學習來掌握。下面我來說說工程師語言的交流體驗。

第一個常見問題是通信的可靠性。從可靠性的角度，通信分為TCP模式和UDP模式。 TCP模式的形象是：我知道你知道。 UDP模式的形象表達是：希望你知道。當然，TCP方式更可靠，但成本相對較高。 UDP模式成本低，但不可靠。通信可靠性有兩個常見錯誤：

第二種溝通問題是及時性。在時效性上，通信分為：同步方式和異步方式。同步通信就像：你現在聽我說。異步通信的形象表達是：記得替我做。溝通及時性有兩個常見錯誤：

有效溝通的一個重要原則是提前溝通。通信的本質是信息的交換和處理，被通信的對象可以比作一個CPU，進行串行信息處理。提前通信意味著盡快將處理請求放入處理隊列。下面這個例子讓很多工程師感到厭惡：一個需求計劃1個月，產品設計2周。開發工程師第一次聽說這個需求時，發現開發時間是2天。工程師爭辯說他會加班一周來完成它。最后得出的結論是，工程師們效率很低，不合作。就像工程師討厭類似的要求一樣。協調一個大項目，希望得到別人的合作，也是要盡快溝通。

有效溝通的另一個關鍵是“不要跑題”。許多看起來非常接近的問題本質上是完全不同的問題。例如：一個會議的主題是“如何執行一個程序”，但有人可能會問“該程序是否應該執行”。 “如何實施”和“應不應該實施”是兩個完全不同的問題，很多看似相關的問題其實都離題很遠。 “跑題”是導致溝通不暢的重要原因。

良好溝通的秘訣在于能夠把握TCP模式和UDP模式的本質，正確判斷問題的緊迫性，盡可能提前溝通，避免跑題。

帶領人的方式

一些初任導師的工程師擔心畢業生的能力太弱。 同樣的事情也發生在許多只管理小團隊的工程師身上。他們的最終結果：寫完所有的代碼，讓下屬沒有代碼可寫。當然，“動手”是很糟糕的。到最后，往往團隊整體業績不高，團隊成員成長緩慢，你累了。

古人云：“勿用疑人，勿用疑人。”這句話不是“一刀切”。在古代，受通信技術的限制，反饋時延顯著，信息傳輸過程中噪聲很大，變形嚴重。在這種情況下it工程師，如果根據短時間內收集到的少量變形信息做出快速決策，很容易草率行事。在公司里，這句話更適合選拔過程，應該改為：不錄用，疑不錄用。

考慮到招聘成本，即使是在招聘層面，有時這也是不可能的。作為一個小團隊的管理者，你可以快速準確地獲得團隊成員的各種反饋信息，絕對沒有必要“用人不疑，不為可疑”。真正的用人理論基礎來自“探索利用”（和）。不能讓下屬做他能做的事，更不能因為下屬失敗就不給機會。

根據經典的“探索利用”（和）理論，好的用人方式應該是：

效率、效率、效率

經常看到一些同學把自己的表現評為100分——滿分，因為過去太難了，但最后的表現卻很一般。天道酬勤勤奮，但天道酬勤。工程師都學過數據結構，不同算法在時間復雜度上的差異，僅僅靠加班是很難彌補的。為了提高工作和學習的效率，我們需要注意以下幾點：

架構師勝任力模型

我們已經講了原理和一些困惑，那么工程師應該如何提高自己呢？

成為一名優秀的架構師是大多數初級和中級工程師的階段性目標。優秀的架構師往往具備七大核心能力：編程能力、調試能力、編譯部署能力、性能優化能力、業務架構能力、在線運維能力、項目管理能力、規劃能力。

這些能力之間的關系大致如下。編程能力、調試能力、編譯部署能力屬于最基本的能力。不掌握這三個能力，就很難實現性能優化能力和業務架構能力。只有具備一定的性能優化能力和業務架構能力，才能在在線運維能力和項目管理能力上表現出色。團隊管理能力是最高能力，更依賴于項目管理能力。

編程能力

對于工程師來說，編程是最基本的能力，也是必不可少的技能。其本質是一種翻譯能力，將業務需求翻譯成機器可以理解的語言。

有很多書籍可以提高您的編程技能。精通面??向對象和設計模式是高效編程的基礎。初級工程師應該編寫更多代碼并閱讀更多代碼。找高手做Code，也是提高編程水平的捷徑。

調試能力

程序代碼是系統的靜態形式。調試的目的是通過查看程序的運行狀態來驗證和優化系統。本質上，工程師可以通過不斷的調試，不斷加強對靜態代碼運行狀態的預測能力。因此，調試能力也是工程師提高編程能力的關鍵手段。很久以前有一個傳說：“調試能力有多強，編程能力就有多強。”不過現在很多編輯器功能非常強大，調試能力的門檻已經大大降低了。

調試能力是項目能否按時高質量提交的關鍵。即使是稍微復雜的項目，大多數工程師也無法在第一時間就完成。大型項目通過不斷的調試得到優化和修正。所以調試能力是必不可少的能力。

編寫更多的程序、解決bug、咨詢更多的專家是提高調試能力的重要手段。

編譯和部署能力

在線編譯和部署運行程序是系統啟動的最后一個環節。隨著SOA架構的普及和業務復雜度的增加，大部分系統只是一個完整業務的一部分。因此，本地編譯運行并不能完全模擬系統的在線運行。為了快速驗證編寫的程序的正確性，在線編譯和部署成為必要的環節。因此，編譯和部署的能力是必備技能。

保持許多相互交織的子系統正常運行可能是一項挑戰。得益于SOA架構的普及和大量編譯部署工具的開發，大大降低了編譯部署的門檻。基于應用層開發的公司，“編譯器工程師”很少。但是對于初級工程師來說，編譯和部署仍然不是一件容易的事。

性能優化功能

衡量系統成功與否的一個重要指標是使用情況。隨著使用量的增加和業務復雜性的增加，大多數系統最終都會遇到性能問題。性能優化能力是一種綜合能力。因為：

可以說，性能優化能力是工程師的各種技能開始融入成長過程的標志。這方面可以參考之前的博文《常用性能優化策略總結》。市面上有很多與性能優化相關的書籍，可以參考。通過閱讀更多關于開源框架中性能優化的文檔和代碼，這也是一個很好的改進方法。手工解決在線性能問題，也是提升性能優化能力的關鍵。如果有機會，向專家學習，分析性能優化方案案例，也是快速提升性能優化能力的一種手段。

在線運維能力

如果說性能優化能力體現的是架構師的靜態思維能力，那么在線運維能力考驗的是動態響應能力。殘酷的現實是，無論程序多么完美，錯誤總是存在的。同時，由于職位更高、責任更大，許多架構師負責非常重要的在線系統。對于線上故障，如果不能及時預防和解決，損失可能難以想象。因此，在線運維能力是優秀架構師必備的技能。

為了快速處理線上故障，標準化的監控、上報、升級、基本的響應機制當然是非常重要的。通過觀察到的現象快速定位、緩解和解決相關癥狀也很關鍵。這就需要架構師對故障系統的業務和技術有一個全面的了解。修復線路故障的建筑師就像 F1 比賽中的車手。賽車手必須了解自己、賽車、對手、同伴、天氣、場地等，快速做出決定，不斷調整。架構師必須了解所有技術細節、業務細節、處理規范、合作伙伴等諸多因素，快速決策并快速調整。

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

業務架構能力

工程師抱怨產品經理的情況并不少見，抱怨最多的主要原因來自于需求的頻繁變化。 There are two main of : the first is or , and the is . For the first , both and have no but to it. A good have the to the of by the .

There are two for the of -:

The first is that the are and . From the of , any is a of and . A needs to go at least three and from the to the and to the . Every time is , there is some loss and some noise, which leads to the fact that the do not meet the at all. In , the side and have weak in , , and cost , which will also lead to .

The is that the side has not about its own needs at all.

A good have the to real and fake . It take time to the real of , have , and the real needs of . The real of the is the . After the real needs of the , a smart have the to judge the 's for , , , etc., and be cost-. , of the and , the of is also the key to a . As the level , the faced by will more and more . To and is the only way for to .

There are some books on the on how to an that you can refer to. , to the , may be a more way. focus on pain than PRD , and focus on real . the and of is also a must for .

As a of the age, of labor and are into the genes of . also need to be for major in order to make a name for . To a as an , is of a must-have skill. In , of and cost is also very .

also means a big heart. Major many such as , , and . In the face of , it is to have a to to the of goals.

that need in : and good use of them, , , and to the truth.

Cost means of , and the need to be :

There are many books on . , is . in big and the way are is also a very means of .

Team

An who doesn't want to be a CTO is not a good . Going to be a plan for . A core of team is , which and . Good needs to the :

There are many books on on the that are worth . is a book, it is the basis of , so you may wish to read it more. from self-, more about other 's plans is also an means to .

總結

I was to share about " while ", the took a while to think about and the , and then kept every day And try to solve the , and then draw the model of based on , and the text.

The the , , and clear goals, to help in their work and study. It be that the of the is full of , and the so- model is also the 's . You are to share your in and in the .