有些事兒，工程師可能此生僅此一次

鄭昀 建立於2016/9/15 最後更新於2016/9/18

關鍵詞：深度思考，碎片化閱讀，作論文，深刻研究，

早先在《技術高手如何煉成》一文中提到，我會問面試者，你平常如何構建本身的知識體系。有人會以爲你怎麼就問出這麼宏大的問題？知識體系，這是什麼鬼？

面試時的交談

——工做以後你作過這樣的事情嗎？

面試是一個誰主張誰舉證的過程，有時候須要面試者舉出實例，自我證實。
而我認爲問一些咱們工做中遇到的難題和業務場景是在「欺負」面試者，因此我喜歡問開放型問題：
在你工做以後，你有沒有像作畢業論文同樣對某一個 Topic 作過深刻研究？若是有，請舉例，說得越詳細越好。

爲何要問這個問題？
由於我和麪試者之間常常會發生這樣的對話：

我：日常看什麼技術網站？
Ta：某某技術新聞站，某某博客網，某某微信公衆號……
我：最近有什麼以爲不錯的文章，印象比較深，能給我講講嗎？
Ta：……
我：#￥^講個標題也行。
Ta：想不起來。
我（汗）：那你日常怎麼學習的？你畢業以後經過哪些方式構建本身的知識體系，講給我聽聽。
Ta：看書（通過追問發現最近幾年其實沒讀完過幾本書，甚至連書名都記不住幾個）。看視頻（網絡教學視頻）。看技術網站（多半停留在首頁上……）。跟朋友聊天（QQ羣，微信羣，……，鬥表情包，無比巨大的噪音）。
我：這樣吧，你工做以後有沒有針對工做中遇到的某一類問題，抽象出一個 Topic，有針對性地調研和作試驗？
Ta：……有吧……
我：你說的這個事兒，其餘公司是怎麼解決的？
Ta：……

新員工的試煉

我會告訴面試者，你來了以後，除了作業務以外，還必須作一個技術預研課題，課題範圍可大可小，你不只僅要作試驗，還要公開分享你的所思所得。

WHY？

由於微信裏收藏10000+篇技術文章，
由於知乎裏收藏10000+個答案，
由於雲筆記裏離線複製了10000+篇文章，
……
很快樂，但並無什麼卵用。

碎片化閱讀是很舒服，但意義不大，看似天天收穫滿滿，其實都成爲過眼煙雲。重複一下著名的學習金字塔留存率觀點：咱們讀過的，知識留存率是10%。

我和麪試者之間還常常會發生這樣的對話：

我：這個思路/技術選型是誰提出來的？
Ta：技術經理/領導/項目經理……
我：有沒有比較過其餘實現思路？請講一下各自的優缺點。
Ta：領導讓這麼幹的，因此沒比較過……

針對某一個課題，深刻思考，多方調研，作試驗證實，不少工程師可能此生僅此一次：他大學畢業時作畢業論文的那次…………

若是長期知足於東點點，西點點，今天多是 Webpack、npm、Gulp，明天多是 Spark、機器學習、流式計算，假設你過目不忘，知識的廣度卻是有了，但缺少深度，久而久之，可能完全毀掉了深度思考的能力。

因此，咱們要「訓練」，強制性要求你從定義問題開始，訓練本身主動搜索、主動連接、主動構建知識、主動試驗、善始善終的能力。

定義問題

首先咱們提出的問題，它必須是有重要意義、急需結果、目標是商用，但可能沒有現成的、肯定的解決方案，同時這個問題必須可以給整個團隊創造學習機會，提供發展我的和組織技能的機會。
那麼經過講述咱們看到了什麼，想解決什麼，經過你我不斷的思考和討論，直到你能清晰地抽象出一個明確具體的問題——這個時候，問題其實已經解決了一半。

舉例。
咱們的平臺由數以百計的形形色色分佈式服務構成，每個請求一路走來，會通過多個業務系統並留下足跡，併產生對各類 Cache 或 DB 的訪問。做爲訪問入口的 App 開發部門首當其衝會接到用戶投訴，然而請求會被隨機分配到集羣的各個節點，因此找到對應的日誌片斷，理清調用關係，找到在哪裏斷的，成爲一個使人生畏的工做。
如何解決？前提是先定義出一個好問題。
拿「分佈式系統」、「集羣」、「日誌」、「排查」等等關鍵字，去搜索，去看各類頂級團隊的博客，去看各類架構師演講資料，終於把問題聚焦於「分佈式跟蹤（Distributed Tracing）」這個命題。
因而，問題被抽象爲一個 Topic：
如何實現分佈式跟蹤：追蹤每一個請求的完整調用鏈路，收集調用鏈路上每一個服務的調用參數和異常堆棧，統計每一個服務的性能數據；可視化調用鏈，可視化服務質量。

主動構建知識

曾經看到過這麼一句話：

只能不斷地學習基礎知識以及和這個技術（問題）關聯的知識，就像 Wikipeida
同樣，當你進入一個詞條的時候，就會伴隨一堆新詞條，因而，當多年後，我看到 「知識廣度是深度的副產品」這句話時，簡直就是說到個人內心去了。

仍以上面的例子舉例。
肯定了分佈式跟蹤的大方向以後，咱們能夠收集整理出各個公司在這個 Topic 上的實踐，Google的Dapper，淘寶的鷹眼，Twitter的ZipKin，京東商城的Hydra，eBay的Centralized Activity Logging (CAL)，大衆點評網的CAT。
接下來咱們還能夠整理出它們的架構思路和優缺點，咱們能夠發現有的解決方案對工程侵入過重，給開發者形成了額外的負擔，有的解決方案依賴於該公司特有的、閉源的技術體系。

主動作試驗

怎麼設計試驗，經過什麼數據，打算證實什麼，這也是一種能力。
舉例。
在實現實時數據大屏的時候，咱們的一位工程師在 MySQL+Canal 後接入分佈式消息隊列時，試驗了 Kafka 和 RocketMQ，目的是，第一求證可否確保嚴格的消息順序，這是數據庫變動訂閱但願看到的，第二作一下壓力測試，比較一下兩者的性能。

善始善終

這裏說的善始善終，包含幾個意思：
畢竟這是一個商業應用，是要上線的，前先後後都要考慮清楚。咱們考慮哪些點？首要的就是監控報警。其次是線上數據如何遷移，線上應用如何接入。再次是性能。
公開分享你的所思所得，不只作，還要寫下來，還要說出來。你必定要輸出你在這個問題上構建的知識結構，幫助本身，幫助你們，共同進步。

如是重複再重複，訓練再訓練，不妨試試看遵循 70-20-10 的學習法則：70%的學習時間放在針對現實生活和工做中遇到的任務、問題解決，20%的學習時間放在人與人之間正式的、非正式的反饋、輔導，10%的時間學習知識和信息（多是碎片化的學習，也多是讀書）。
這樣可能像把你裝進一個沙袋裏吊起來，從四面八方用狼牙棒打你，酣暢淋漓。

-EOF-