這篇文章，對于每一個想成為技術大牛的人來說都值得仔細閱讀好幾遍。

[[278938]] 

圖片來自 Pexels

雙生說：曹樂是典型學霸，清華本碩，多年互聯(lián)網(wǎng)大廠研發(fā)經(jīng)驗，所以“資深”。我剛到新部門的時候，約各位合作部門的 Leader 請教，也算幫我做新崗位入職的“平穩(wěn)降落”。

印象最深的，就是作為技術 Leader 的曹樂，一點都不像技術——他和我談對業(yè)務的理解，各個維度的見解與想法，讓人印象深刻。

然后，他很熱情的幫我安排了他團隊幾個同學的 1-1，幫助我了解了更多從技術視角對業(yè)務與技術團隊協(xié)同、共創(chuàng)的思考。

后來，開始深入合作，發(fā)現(xiàn)合作的技術同學，不僅僅技術上追求精進，而且是真正的也能夠跳出來去看業(yè)務全局。能跳出來，能跳進去。

這封信，是曹樂寫給團隊的。如何成為技術大牛(來自另一學霸同事的評論，感謝)：尋找范式、刻意練習、及時反饋;垂直打透、橫向遷移、深度復盤;聰明人要下笨功夫。

Enjoy~

接納焦慮

很多同學都有關于工程師該如何成長的問題，大家普遍對如何成長為牛人，如何獲得晉升，如何在繁忙的工作中持續(xù)學習充滿了困惑，這其實是每一位同學成長過程中必經(jīng)之路。

最近幾次 1-1 也和同學聊過這方面的問題。在這里也想跟大家分享一下我的一些心得。

同學們普遍對成長充滿了焦慮感。工作太忙沒時間學習，需求太多太瑣碎感覺自己沒什么進步，做技術是不是做到 35 歲以后就沒人要了，等等，都是對成長焦慮的體現(xiàn)。

在這里我想說的是，這種焦慮是正常的，所有的渴望，在內(nèi)心的投射其實都是焦慮。

任何一個渴望成長的人，不管處于什么階段，一線工程師，架構(gòu)師，還是總監(jiān)，副總裁，其實內(nèi)心中都是充滿了焦慮的，無一例外。

對于這種焦慮，我們所要做的是接納，而不需要過度擔憂。這種焦慮并不是說，想明白如何成長了就會沒有了，到了某個階段就會沒有了的。

成長的腳步和期待一刻不止，內(nèi)心的焦慮也一刻不會停歇。正是這種焦慮感，驅(qū)使你寫代碼追查問題到星夜，驅(qū)使你犧牲休息娛樂的時間和一本本厚厚枯燥的書作伴，驅(qū)使你不斷努力向前，不舍晝夜。

相反的，如果內(nèi)心中沒有這種焦慮，反而是值得擔憂的。這可能說明已經(jīng)習慣呆在自己的舒適區(qū)了。

在現(xiàn)在這樣一個高速發(fā)展的社會，以及我們這樣一個高速發(fā)展和變化的行業(yè)，失去對成長的渴望和焦慮反而是一個非常危險的信號。

[[278939]] 

35 歲危機

所謂的程序員 35 歲危機，其實背后的根本原因是，有太多太多人在工作幾年以后，就覺得自己什么都會了，之后的十幾年工作只不過是頭 2-3 年的簡單重復而已。

在我們這樣一個行業(yè)里，在招聘的時候，如果擺在管理面前的兩個：

• 一個是初出茅廬或剛工作 2-3 年，充滿了對成長的渴望。
• 另一個工作十多年了但水平和工作 2-3 年的人差不多，只是更熟練一些，不過在舒適區(qū)已經(jīng)躺了十年了。

如果負責招聘的是你，你會做出什么樣的選擇?而另一方面，其實是高端人才在行業(yè)內(nèi)的極度極度稀缺。

大家可以想一想，我們部門上一次招聘到 D10 及以上的同學是什么時候?從業(yè)務平臺部 2016 年中成立到現(xiàn)在，一個都沒有過。

D9 同學也是鳳毛麟角，一年能招到 1-2 個就足夠可以偷著樂了。面試碰到牛人的時候，就如同相親碰到女神一樣激動。這在行業(yè)內(nèi)是非常普遍的現(xiàn)象，真正的大牛太稀缺了。

在這樣一個行業(yè)里，如果一個人能夠持續(xù)成長，能力和工作年限成正比的持續(xù)提升，這樣的人，任何時候在行業(yè)里都是被瘋搶，怎么可能會遇到任何年齡的危機呢?

每一個業(yè)務平臺技術部的同學，都應該立志成為這樣的大牛，持續(xù)學習和成長。

[[278940]] 

刻意練習三步法

如何學習，其實是有方法論的，那就是刻意練習。所謂的 10000 小時成為大牛的理論是片面的，如果只是簡單重復 10000 小時，是不可能成為大牛的。

刻意練習包含了三個步驟：

• 找到你要學習的這個領域體系的范式(Pattern)
• 針對每個范式刻意的反復學習和練習
• 及時反饋

大家在過往的工作和學習生活中，或多或少都在實踐著刻意練習。拿面臨高考的中學生舉例子。

好的學生通常是把一門功課拆成了很多知識點(尋找 Pattern)，然后針對知識點以及他們的排列組合，有針對性的反復做各種難度的題(刻意練習)。

每次做完題都對一下答案看看正確與否，如果錯了就思考，記錄，復盤(持續(xù)及時反饋)。這樣的學習方法就是事半功倍的。

而事倍功半的學習方法，就是不分青紅皂白拿起一本習題或卷子就拼命做，我上學的時候身邊不少同學非常勤奮但成績并不好，多半都是這個原因。

再舉一個我最近在學打羽毛球的例子，正確的學習方法是把打羽毛球拆解成步法和手上動作，小碎步，米字步，正反手挑球，放網(wǎng)，正手和頭頂高遠球吊球殺球等(尋找 Pattern)。

然后針對每一個動作反復練習(刻意練習)，然后請教練或者錄下來看視頻糾正自己的動作(及時反饋)。

而錯誤的學習方法是，上來就盲目找人打比賽，以賽代練，這樣的進步是很慢的，而且錯誤的動作形成習慣以后未來反而很難糾正。

當學習方法不正確的時候，刻苦的學習常常只是看起來很勤奮，并沒有應有的效果。

當接觸一個陌生領域的時候，錯誤的學習方法是不帶目的性，上來就找一堆相關的大部頭開始啃。

而正確的學習方法應該是快速梳理該領域的知識點，形成框架體系(尋找 Pattern)，這里有些小竅門可以快速構(gòu)建起一個領域的知識點體系。

例如看一些該領域的綜述性或開創(chuàng)性的文章(看論文，別瞎看網(wǎng)上的文章)，或者找本該領域綜述性的教科書看它的目錄(注意，好的教科書的目錄往往就是這個領域的知識框架，內(nèi)容倒不一定非要看下去)。

然后，針對每個知識點，找書里的相關章節(jié)，該領域相關 Paper 里的相關 Section 深入學習，建立起自己對這個知識點的理解(刻意練習)。

最后，再把知識點和現(xiàn)實工作中的情況(自己工作，或其他公司相關的工作)進行對照(及時反饋)，從而建立對一個知識點的深度理解，最后融會貫通建立對一個領域的理解。

這樣說可能有點抽象，拿我當年學習分布式存儲的過程為例子，先結(jié)合自己的工作內(nèi)容梳理出需要深入了解的知識點。

例如，元信息組織、Meta Server 設計和 HA、副本組織和管理、Recovery、Rebalance、單機存儲引擎、數(shù)據(jù)/元信息流、糾刪碼、一致性、多租戶、存儲介質(zhì)、網(wǎng)絡環(huán)境和 IDC 等等。

同時看很多綜述性的材料，梳理分布式存儲的知識點(有網(wǎng)上各種整理的比較好的文章，也有從各種系統(tǒng)實現(xiàn)的 Paper 里抽出)，不斷迭代構(gòu)建分布式存儲領域的知識點(尋找 Pattern，這是最難的一個過程)。

然后針對每一個知識點，找相關材料進行深度學習，例如，對于分布式一致性，需要閱讀 CAP 理論，Paxos 的論文，Raft 的論文等等，以及周邊的很多材料(刻意練習)。

然后找各種系統(tǒng)實現(xiàn)的論文或文章，比如 GFS，Dynamo，Aurora，OceanBase，Ceph，Spanner 等等，看看和對比它們在一致性上是如何考慮和取舍的。

當然，最重要的是結(jié)合自己工作中的反復實踐和所學知識點進行比對(及時反饋)。

這三個階段并不是割裂的，而是周而復始的，經(jīng)常會在刻意練習和及時反饋的學習過程中，發(fā)現(xiàn)自己遺漏的知識點，或者發(fā)現(xiàn)自己梳理的兩個知識點其實是重合的。

通過這種交叉比對，以及在實踐中不斷檢驗的方式建立的知識點是非?？陕涞氐?，而不會看了幾篇論文以后就人云亦云。

拿分布式存儲的一致性舉例子，如果不是反復對比、思考和反復實踐，你不會發(fā)現(xiàn) GFS 論文里最難的一段，多個 Writer 對一個文件進行 Append 的邏輯，在實踐中根本沒用。

你也不會發(fā)現(xiàn)看起來優(yōu)雅而學術的 CAP 三選二的理論，實踐中壓根不是這么完美，很多時候只能三選一。

你也不會發(fā)現(xiàn) Dynamo 論文里的 Vector Clock，網(wǎng)上有無數(shù)文章?lián)u頭晃腦的解讀，但在 Amazon 的應用場景里是個典型的 over design，Cassandra 在這點就務實很多。

這時候大家可能會有個疑問，工作本身就如此繁忙了，哪里能抽出足夠多的時間去學習?

 

工作和學習并不割裂

其實工作和學習本身，是不應該被割裂的。工作本來就應該是學習的一部分，是學習中的實踐和及時反饋的部分。學習如果脫離工作的實踐，是非常低效的。

因此每個同學應該對自己工作所在的這個技術和業(yè)務領域進行系統(tǒng)性的學習，并在工作中反復實踐和驗證。

不同的領域之間其實是融匯貫通的，當你對一個領域精通并總結(jié)出方法論以后，很容易就能上手別的領域。

因此花幾年實踐徹底研究透一個領域，對于剛工作幾年的同學來說，是非常重要，甚至是必須的，也只有在一個領域打透之后才談得上跨領域遷移，去拓展自己的知識面。

更直接的說，對于一個領域還未完全掌握的同學，深度是最重要的，不用想廣度的事情，等掌握了一個領域之后，再去拓展廣度就變得很容易了。

這里一個常見的誤區(qū)是，學習的內(nèi)容和工作的領域沒有太多直接的關系。

例如，我以前曾經(jīng)花了非常大的功夫去讀 Linux 內(nèi)核的源代碼以及很多相關的大部頭，幾乎花掉了我將近兩年的所有空閑時間。

然而在我這些年的工作里，幾乎是沒有用處的，最多就是有一些“啟發(fā)”，ROI 實在是太低了，現(xiàn)在也忘得差不多了。

更重要的，軟件工程是一門實踐科學，從書本上得到的知識如果沒有在實踐中應用和檢驗，基本上是沒有用處的。

舉一個例子，很多優(yōu)秀的架構(gòu)師，盡管日常工作中可能反復在用，但未必說得出開閉原則，里氏替換原則，迪米特法則等等。

反過來，對面向?qū)ο笤O計這 7 大原則出口成章的人，很多其實離真正的架構(gòu)師還遠得很，有些甚至只是博客架構(gòu)師而已。

實踐遠遠比看書，看文章重要得多，上文所述的我構(gòu)建自己分布式存儲知識體系的過程，看起來好像都是看材料，看論文，而實際上 80% 的收獲都來源于帶著理論的實踐，和從實踐中總結(jié)沉淀的理論。

因此，徹底搞明白自己工作所在的技術和業(yè)務領域，是最務實高效的做法，工作和學習割裂，會導致工作和學習都沒做好。

這時候大家可能會有另一個疑問，感覺日常工作非?，嵥?，學不到什么東西，怎么辦?

如果把學習分成從書本中學，和從工作中學這兩種的話，那毫無疑問，工作中的“知識密度”，比起書本的“知識密度”，肯定是要低很多的，因為書本里的知識，那都是人家從他們的工作中抽象總結(jié)出來的。

這也是為什么大家普遍覺得日常工作“瑣碎”。然而工作中每個點滴的瑣事與平凡，都是可以抽象總結(jié)成為方法論的，更別說工作所在的領域自身的博大精深了。從日常工作中學習的秘訣，就是“行動中思考”。

[[278941]] 

優(yōu)秀架構(gòu)師的兩大能力

對于每一個軟件工程師，最重要的兩個能力：

• 寫代碼
• Trouble Shooting

并且，要成為優(yōu)秀的架構(gòu)師，出色的開發(fā)能力和追查問題的能力是一切的基礎。

提高寫代碼的能力的核心，首先在于堅持不斷的寫，但更重要的，在于每天，每周，持續(xù)不斷的 Review 自己之前的代碼，同時，多 Review 牛人寫的代碼。

比如團隊里你覺得代碼寫的比你好的同事，比如社區(qū)里以代碼漂亮著稱的開源代碼(作為一個 C++ 程序員，當年我的榜樣之一是 Boost 庫)。一旦覺得自己之前的代碼不夠好，就立刻復盤，立刻重構(gòu)。

更重要的是，多思考自己代碼和好的代碼之間不同之處背后的為什么，通常這就是為什么這些代碼更好的背后的秘密。

特別要說明的是，代碼規(guī)范除了知道是什么外，要格外重視思考每一個代碼規(guī)范背后的為什么。代碼規(guī)范的每一句話，背后無一例外都是一片江湖上的血淚史。

要提高 Trouble Shooting 的能力，關鍵在于要深度復盤自己遇到的每一個問題，包括線上的，包括測試發(fā)現(xiàn)的。

尋找每一個問題，每一次事故背后的 Root Cause，并且思考后續(xù)如何避免同類問題，如何更快的發(fā)現(xiàn)同類問題。

要對團隊內(nèi)外遇到的所有問題都要保持好奇心，關注一下周邊的事故、問題背后的 Root Cause。

Trouble Shooting 能力的提高是幾乎無法從書本上得到的，完全來源于對每一個問題的深度思考，以及廣泛積累每一個問題。

對于架構(gòu)師而言，可能未必在一線寫代碼了，但看團隊中一個架構(gòu)師是否真正牛逼的一個很重要標準，就是看他是否能夠追查出團隊其他同學查不出來的問題。

我見過的一個真正牛逼的架構(gòu)師，對于系統(tǒng)中疑難雜癥，通常問幾個問題，就能大致猜出是哪里出的問題，以及可能的原因是什么，準確程度如同算命，屢試不爽，令人嘆為觀止。

對于一個架構(gòu)師，除了更加優(yōu)秀的代碼能力和 Trouble Shooting 能力外，需要構(gòu)建相對完整的當前技術領域的知識體系，需要有體系化的思維能力，需要對技術所服務的業(yè)務有非常深入的了解。

體系化的思維能力，來源于兩個方面。一方面是在日常工作中，對每一個接口設計，每一個邏輯，每一個模塊，子系統(tǒng)的拆分和組織方式，每一個需求的技術方案，每一個系統(tǒng)的頂層設計，都要反復思考和推敲，不斷的復盤。

另一方面，需要大量廣泛的學習行業(yè)內(nèi)相似系統(tǒng)的架構(gòu)設計，這其實就是開天眼，只是技術相對來說，行業(yè)內(nèi)的交流更加頻繁。

淘寶、美團、百度、Google、Facebook、Amazon 等各個公司介紹系統(tǒng)架構(gòu)的論文和 PPT 鋪天蓋地，需要帶著問題持續(xù)學習。

除了技術領域本身外，架構(gòu)師需要非常了解業(yè)務上是如何使用我們的系統(tǒng)的，否則非常容易 Over Design，陷入技術的自嗨中。

這也是為什么我說 Amazon Dynamo 論文里講的 Vector Clock 是個 Over Design 的原因。

另一方面，很多時候技術上繞不過去的坎，可能非常復雜的實現(xiàn)，往往只需要上層業(yè)務稍微變通一下，就完全可以繞過去。

這也是為什么我說 GFS 論文里，多個 Writer 同時 Append 同一個文件是個根本沒用的設計(實際上 Google 內(nèi)部也把這個功能去掉了)。

這也是為什么我在咱們部門內(nèi)反復強調(diào)大家需要深入了解業(yè)務，因為達到同樣的業(yè)務目標，可能稍微改一下產(chǎn)品方案就可以讓需求的技術實現(xiàn)變得無比簡單。

只有真正知道上層業(yè)務是如何使用系統(tǒng)的，才可能真正做好架構(gòu)。

深入了解業(yè)務并不難，對于每個同學，只要對于每一個接到的需求，對于每一個需求評審中的需求，對于周邊同學或團隊要做的需求，都深入思考為什么業(yè)務要提出這個需求，這個需求解決了業(yè)務的什么問題，有沒有更好的方案。

遇到不明白的多和周邊同學、產(chǎn)品、運營同學請教。最怕的是自己把自己限定為純粹的研發(fā)，接到需求就無腦做，這等于放棄了主動思考。

衡量一個人是不是好的架構(gòu)師，也有一個方法。對于一個需求，如果他給出了好幾個可行的方案，說這些方案也可以，那些方案也可以，往往說明他在架構(gòu)師的路上還沒有完全入門。

架構(gòu)師的難點不在于給出方案，而在于找到唯一的那一個最簡單優(yōu)雅的方案。

總結(jié)起來看，行動中思考，就是始終保持好奇，不斷從工作中發(fā)現(xiàn)問題，不斷帶著問題回到工作中去;不斷思考，不斷在工作中驗證思考;不斷從工作中總結(jié)抽象，不斷對工作進行復盤，持續(xù)不斷把工作內(nèi)容和全領域的知識交叉驗證，反復實踐的過程。

在工作所在的技術和業(yè)務領域中刻意練習，加上行動中思考，就是成為技術大牛的秘訣。

看起來方法也不復雜，為什么大牛還是非常稀少?

盡管我們通篇都在講方法，但其實在成為技術大牛的路上，方法反而是沒那么重要的。

真正困難的，在于數(shù)年，數(shù)十年如一日的堅持。太多人遇到挫折，遇到瓶頸，就覺得手頭的事情太乏味枯燥，就想要換一個方向，換一個領域，去學新的技術，新的東西。

而真正能夠成為大牛的，必須是能夠青燈古佛，熬得住突破瓶頸前長時間的寂寞的，必須是肯下笨功夫的聰明人。

因此，和堅持相比，方法其實并沒有那么重要。和大家共勉。