深度好文 | 資深技術Leader曹樂：如何成爲技術大牛

雙生說：曹樂是典型學霸，清華本碩，多年互聯網大廠研發經驗，因此「資深」。我剛到新部門的時候，約各位合做部門的Leader請教，也算幫我作新崗位入職的「平穩降落」。印象最深的，就是做爲技術Leader的曹樂，一點都不像技術——他和我談對業務的理解，各個維度的看法與想法，讓人印象深入。而後，他很熱情的幫我安排了他團隊幾個同窗的1-1，幫助我瞭解了更多從技術視角對業務與技術團隊協同、共創的思考。後來，開始深刻合做，發現合做的技術同窗，不只僅技術上追求精進，並且是真正的也可以跳出來去看業務全局。能跳出來，能跳進去。

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

Enjoy~

不少同窗都有關於工程師該如何成長的問題，你們廣泛對如何成長爲牛人，如何得到晉升，如何在繁忙的工做中持續學習充滿了困惑，這實際上是每一位同窗成長過程當中必經之路。最近幾回1-1也和同窗聊過這方面的問題。在這裏也想跟你們分享一下個人一些心得。

同窗們廣泛對成長充滿了焦慮感。工做太忙沒時間學習，需求太多太瑣碎感受本身沒什麼進步，作技術是否是作到35歲之後就沒人要了，等等，都是對成長焦慮的體現。在這裏我想說的是，這種焦慮是正常的，全部的渴望，在心裏的投射其實都是焦慮。任何一個渴望成長的人，無論處於什麼階段，一線工程師，架構師，仍是總監，副總裁，其實心裏中都是充滿了焦慮的，無一例外。對於這種焦慮，咱們所要作的是接納，而不須要過分擔心。這種焦慮並非說，想明白如何成長了就會沒有了，到了某個階段就會沒有了的。成長的腳步和期待一刻不止，心裏的焦慮也一刻不會停歇。正是這種焦慮感，驅使你寫代碼追查問題到星夜，驅使你犧牲休息娛樂的時間和一本本厚厚枯燥的書做伴，驅使你不斷努力向前，不捨晝夜。相反的，若是心裏中沒有這種焦慮，反而是值得擔心的。這可能說明已經習慣呆在本身的溫馨區了。在如今這樣一個高速發展的社會，以及咱們這樣一個高速發展和變化的行業，失去對成長的渴望和焦慮反而是一個很是危險的信號。

所謂的程序員35歲危機，其實背後的根本緣由是，有太多太多人在工做幾年之後，就以爲本身什麼都會了，以後的十幾年工做只不過是頭2-3年的簡單重複而已。在咱們這樣一個行業裏，在招聘的時候，若是擺在管理面前的兩我的，一個是初出茅廬或剛工做2-3年，充滿了對成長的渴望；另外一個工做十多年了但水平和工做2-3年的人差很少，只是更熟練一些，不過在溫馨區已經躺了十年了。若是負責招聘的是你，你會作出什麼樣的選擇？

而另外一方面，實際上是高端人才在行業內的極度極度稀缺。你們能夠想想，咱們部門上一次招聘到D10及以上的同窗是何時？從業務平臺部2016年中成立到如今，一個都沒有過。D9同窗也是百裏挑一，一年能招到1-2個就足夠能夠偷着樂了。面試碰到牛人的時候，就如同相親碰到女神同樣激動。這其實在行業內是很是廣泛的現象，真正的大牛太稀缺了。在這樣一個行業裏，若是一我的可以持續成長，能力和工做年限成正比的持續提高，這樣的人，任什麼時候候在行業裏都是被瘋搶，怎麼可能會遇到任何年齡的危機呢？

每個業務平臺技術部的同窗，都應該立志成爲這樣的大牛，持續學習和成長。

如何學習，實際上是有方法論的，那就是刻意練習。所謂的10000小時成爲大牛的理論是片面的，若是隻是簡單重複10000小時，是不可能成爲大牛的。刻意練習包含了三個步驟。第一，找到你要學習的這個領域體系的範式（pattern）；第二，針對每一個範式刻意的反覆學習和練習；第三，及時反饋。

你們在過往的工做和學習生活中，或多或少都在實踐着刻意練習。拿面臨高考的中學生舉例子，好的學生一般是把一門功課拆成了不少知識點（尋找pattern），而後針對知識點以及他們的排列組合，有針對性的反覆作各類難度的題（刻意練習），每次作完題都對一下答案看看正確與否，若是錯了就思考，記錄，覆盤（持續及時反饋）。這樣的學習方法就是事半功倍的。而事倍功半的學習方法，就是不分青紅皁白拿起一本習題或卷子就拼命作，我上學的時候身邊很多同窗很是勤奮但成績並很差，多半都是這個緣由。再舉一個我最近在學打羽毛球的例子，正確的學習方法是把打羽毛球拆解成步法和手上動做，小碎步，米字步，正反手挑球，放網，正手和頭頂高遠球吊球殺球等（尋找pattern），而後針對每個動做反覆練習（刻意練習），而後請教練或者錄下來看視頻糾正本身的動做（及時反饋）；而錯誤的學習方法是，上來就盲目找人打比賽，以賽代練，這樣的進步是很慢的，並且錯誤的動做造成習慣之後將來反而很難糾正。

當學習方法不正確的時候，刻苦的學習經常只是看起來很勤奮，並無應有的效果。當接觸一個陌生領域的時候，錯誤的學習方法是不帶目的性，上來就找一堆相關的大部頭開始啃。而正確的學習方法應該是快速梳理該領域的知識點，造成框架體系（尋找pattern），這裏有些小竅門能夠快速構建起一個領域的知識點體系，例如看一些該領域的綜述性或開創性的文章（看論文，別瞎看網上的文章），或者找本該領域綜述性的教科書看它的目錄（注意，好的教科書的目錄每每就是這個領域的知識框架，內容倒不必定非要看下去）。而後，針對每一個知識點，找書裏的相關章節，該領域相關paper裏的相關section深刻學習，創建起本身對這個知識點的理解（刻意練習）。最後，再把知識點和現實工做中的狀況（本身工做，或其餘公司相關的工做）進行對照（及時反饋），從而創建對一個知識點的深度理解，最後融會貫通創建對一個領域的理解。這樣說可能有點抽象，拿我當年學習分佈式存儲的過程爲例子，先結合本身的工做內容梳理出須要深刻了解的知識點（例如，元信息組織，Meta Server設計和HA，副本組織和管理，Recovery，Rebalance，單機存儲引擎，數據/元信息流，糾刪碼，一致性，多租戶，存儲介質，網絡環境和IDC等等），同時看不少綜述性的材料，梳理分佈式存儲的知識點（有網上各類整理的比較好的文章，也有從各類系統實現的paper裏抽出），不斷迭代構建分佈式存儲領域的知識點（尋找pattern，這是最難的一個過程）；而後針對每個知識點，找相關材料進行深度學習，例如，對於分佈式一致性，須要閱讀CAP理論，Paxos的論文，Raft的論文等等以及周邊的不少材料（刻意練習）；而後找各類系統實現的論文或文章，好比GFS，Dynamo，Aurora，OceanBase，Ceph，Spanner等等，看看和對比它們在一致性上是如何考慮和取捨的，固然，最重要的是結合本身工做中的反覆實踐和所學知識點進行比對（及時反饋）。這三個階段並非割裂的，而是周而復始的，常常會在刻意練習和及時反饋的學習過程當中，發現本身遺漏的知識點，或者發現本身梳理的兩個知識點實際上是重合的。經過這種交叉比對，以及在實踐中不斷檢驗的方式創建的知識點是很是可落地的，而不會看了幾篇論文之後就人云亦云。拿分佈式存儲的一致性舉例子，若是不是反覆對比、思考和反覆實踐，你不會發現GFS論文裏最難的一段，多個Writer對一個文件進行append的邏輯，在實踐中根本沒用；你也不會發現看起來優雅而學術的CAP三選二的理論，實踐中壓根不是這麼完美，不少時候只能三選一；你也不會發現Dynamo論文裏的Vector Clock，網上有無數文章搖頭晃腦的解讀，但在Amazon的應用場景裏是個典型的over design，Cassandra在這點就務實不少。

這時候你們可能會有個疑問，工做自己就如此繁忙了，哪裏能抽出足夠多的時間去學習？

其實工做和學習自己，是不該該被割裂的。工做原本就應該是學習的一部分，是學習中的實踐和及時反饋的部分。學習若是脫離工做的實踐，實際上是很是低效的。所以每一個同窗應該對本身工做所在的這個技術和業務領域進行系統性的學習，並在工做中反覆實踐和驗證。不一樣的領域之間實際上是融匯貫通的，當你對一個領域精通並總結出方法論之後，很容易就能上手別的領域。所以花幾年實踐完全研究透一個領域，對於剛工做幾年的同窗來講，是很是重要，甚至是必須的，也只有在一個領域打透以後才談得上跨領域遷移，去拓展本身的知識面。更直接的說，對於一個領域還未徹底掌握的同窗，深度是最重要的，不用想廣度的事情，等掌握了一個領域以後，再去拓展廣度就變得很容易了。這裏一個常見的誤區是，學習的內容和工做的領域沒有太多直接的關係。例如，我之前曾經花了很是大的功夫去讀Linux內核的源代碼以及不少相關的大部頭，幾乎花掉了我將近兩年的全部空閒時間，然而在我這些年的工做裏，幾乎是沒有用處的，最多就是有一些「啓發」，ROI實在是過低了，如今也忘得差很少了。更重要的，軟件工程是一門實踐科學，從書本上獲得的知識若是沒有在實踐中應用和檢驗，基本上是沒有用處的。舉一個例子，不少優秀的架構師，儘管平常工做中可能反覆在用，但未必說得出開閉原則，里氏替換原則，迪米特法則等等，反過來，對面向對象設計這7大原則出口成章的人，不少其實離真正的架構師還遠得很，有些甚至只是博客架構師而已。實踐遠遠比看書，看文章重要得多，上文所述的我構建本身分佈式存儲知識體系的過程，看起來好像都是看材料，看論文，而實際上80%的收穫都來源於帶着理論的實踐，和從實踐中總結沉澱的理論。所以，完全搞明白本身工做所在的技術和業務領域，是最務實高效的作法，工做和學習割裂，會致使工做和學習都沒作好。

這時候你們可能會有另外一個疑問，感受平常工做很是瑣碎，學不到什麼東西，怎麼辦？

若是把學習分紅從書本中學，和從工做中學這兩種的話，那毫無疑問，工做中的「知識密度」，比起書本的「知識密度」，確定是要低不少的，由於書本里的知識，那都是人家從他們的工做中抽象總結出來的。這也是爲何你們廣泛以爲平常工做「瑣碎」。然而工做中每一個點滴的雜事與平凡，都是能夠抽象總結成爲方法論的，更別說工做所在的領域自身的博大精深了。從平常工做中學習的祕訣，就是「行動中思考」。

對於每個軟件工程師，最重要的兩個能力，是寫代碼的能力和trouble shooting的能力。而且，要成爲優秀的架構師，出色的開發能力和追查問題的能力是一切的基礎。提升寫代碼的能力的核心，首先在於堅持不斷的寫，但更重要的，在於天天，每週，持續不斷的review本身以前的代碼；同時，多review牛人寫的代碼，好比是團隊裏你以爲代碼寫的比你好的同事，好比社區裏以代碼漂亮著稱的開源代碼（做爲一個C++程序員，當年個人榜樣之一是boost庫）。一旦以爲本身以前的代碼不夠好，就馬上覆盤，馬上重構。更重要的是，多思考本身代碼和好的代碼之間不一樣之處背後的爲何，一般這就是爲何這些代碼更好的背後的祕密。特別要說明的是，代碼規範除了知道是什麼外，要格外重視思考每個代碼規範背後的爲何。代碼規範的每一句話，背後無一例外都是一片江湖上的血淚史。要提升trouble shooting的能力，關鍵在於要深度覆盤本身遇到的每個問題，包括線上的，包括測試發現的，尋找每個問題，每一次事故背後的root cause，而且思考後續如何避免同類問題，如何更快的發現同類問題。要對團隊內外遇到的全部問題都要保持好奇心，關注一下週邊的事故、問題背後的root cause。Trouble shooting能力的提升是幾乎沒法從書本上獲得的，徹底來源於對每個問題的深度思考，以及普遍積累每個問題。對於架構師而言，可能未必在一線寫代碼了，但看團隊中一個架構師是否真正牛逼的一個很重要標準，就是看他是否可以追查出團隊其餘同窗查不出來的問題。我見過的一個真正牛逼的架構師，對於系統中疑難雜症，一般問幾個問題，就能大體猜出是哪裏出的問題，以及可能的緣由是什麼，準確程度如同算命，屢試不爽，使人歎爲觀止。

對於一個架構師，除了更加優秀的代碼能力和trouble shooting能力外，須要構建相對完整的當前技術領域的知識體系，須要有體系化的思惟能力，須要對技術所服務的業務要有很是深刻的瞭解。體系化的思惟能力，來源於兩個方面。一方面是在平常工做中，對每個接口設計，每個邏輯，每個模塊，子系統的拆分和組織方式，每個需求的技術方案，每個系統的頂層設計，都要反覆思考和推敲，不斷的覆盤。另外一方面，須要大量普遍的學習行業內類似系統的架構設計，這其實就是開天眼，只是技術相對來講，行業內的交流更加頻繁，淘寶、美團、百度、Google、Facebook、Amazon等各個公司介紹系統架構的論文和PPT鋪天蓋地，須要帶着問題持續學習。除了技術領域自己外，架構師須要很是瞭解業務上是如何使用咱們的系統的，不然很是容易over design，陷入技術的自嗨中，這也是爲何我說Amazon Dynamo論文裏講的Vector Clock是個over design的緣由。另外一方面，不少時候技術上繞不過去的坎，可能很是複雜的實現，每每只須要上層業務稍微變通一下，就徹底能夠繞過去，這也是爲何我說GFS論文裏，多個Writer同時Append同一個文件是個根本沒用的設計（實際上Google內部也把這個功能去掉了）。這也是爲何我在我們部門內反覆強調你們須要深刻了解業務，由於達到一樣的業務目標，可能稍微改一下產品方案就可讓需求的技術實現變得無比簡單。只有真正知道上層業務是如何使用系統的，纔可能真正作好架構。 深刻了解業務並不難，對於每一個同窗，只要對於每個接到的需求，對於每個需求評審中的需求，對於周邊同窗或團隊要作的需求，都深刻思考爲何業務要提出這個需求，這個需求解決了業務的什麼問題，有沒有更好的方案。遇到不明白的多和周邊同窗、產品、運營同窗請教。最怕的是本身把本身限定爲純粹的研發，接到需求就無腦作，這等於放棄了主動思考。衡量一我的是否是好的架構師，也有一個方法。對於一個需求，若是他給出了好幾個可行的方案，說這些方案也能夠，那些方案也能夠，每每說明他在架構師的路上尚未徹底入門。架構師的難點不在於給出方案，而在於找到惟一的那一個最簡單優雅的方案。

總結起來看，行動中思考，就是始終保持好奇，不斷從工做中發現問題，不斷帶着問題回到工做中去；不斷思考，不斷在工做中驗證思考；不斷從工做中總結抽象，不斷對工做進行復盤，持續不斷把工做內容和全領域的知識交叉驗證，反覆實踐的過程。

在工做所在的技術和業務領域中刻意練習，加上行動中思考，就是成爲技術大牛的祕訣。

看起來方法也不復雜，爲何大牛仍是很是稀少？

儘管咱們通篇都在講方法，但其實在成爲技術大牛的路上，方法反而是沒那麼重要的。真正困難的，在於數年，數十年如一日的堅持。太多人遇到挫折，遇到瓶頸，就以爲手頭的事情太乏味枯燥，就想要換一個方向，換一個領域，去學新的技術，新的東西。而真正可以成爲大牛的，必須是可以青燈古佛，熬得住突破瓶頸前長時間的寂寞的，必須是肯下笨功夫的聰明人。所以，和堅持相比，方法其實並無那麼重要。

和你們共勉。

（完）