有些事儿，工程师可能今生仅此一次
鄭昀 創(chuàng)建于2016/9/15 最后更新于2016/9/18
關鍵詞：深度思考，碎片化閱讀，做論文，深入研究，
早先在《技術高手如何煉成》一文中提到，我會問面試者，你日常如何構建自己的知識體系。有人會覺得你怎么就問出這么宏大的問題？知識體系，這是什么鬼？
面試時的交談
工作之后你做過這樣的事情嗎？
面試是一個誰主張誰舉證的過程，有時候需要面試者舉出實例，自我證明。
而我認為問一些我們工作中遇到的難題和業(yè)務場景是在“欺負”面試者，所以我喜歡問開放型問題：
在你工作之后，你有沒有像做畢業(yè)論文一樣對某一個 Topic 做過深入研究？如果有，請舉例，說得越詳細越好。
為什么要問這個問題？
因為我和面試者之間經常會發(fā)生這樣的對話：
我：平常看什么技術網站？
Ta：某某技術新聞站，某某博客網，某某微信公眾號……
我：最近有什么覺得不錯的文章，印象比較深，能給我講講嗎？
Ta：……
我：#￥^&#講個標題也行。
Ta：想不起來。
我（汗）：那你平常怎么學習的？你畢業(yè)之后通過哪些方式構建自己的知識體系，講給我聽聽。
Ta：看書（經過追問發(fā)現(xiàn)最近幾年其實沒讀完過幾本書，甚至連書名都記不住幾個）。看視頻（網絡教學視頻）。看技術網站（多半停留在首頁上……）。跟朋友聊天（QQ群，微信群，……，斗表情包，無比巨大的噪音）。
我：這樣吧，你工作之后有沒有針對工作中遇到的某一類問題，抽象出一個 Topic，有針對性地調研和做試驗？
Ta：……有吧……
我：你說的這個事兒，其他公司是怎么解決的？
Ta：……
新員工的試煉
我會告訴面試者，你來了之后，除了做業(yè)務之外，還必須做一個技術預研課題，課題范圍可大可小，你不僅僅要做試驗，還要公開分享你的所思所得。
WHY？
因為微信里收藏10000+篇技術文章，
因為知乎里收藏10000+個答案，
因為云筆記里離線復制了10000+篇文章，
……
很快樂，但并沒有什么卵用。
碎片化閱讀是很舒服，但意義不大，看似每天收獲滿滿，其實都成為過眼煙云。重復一下著名的學習金字塔留存率觀點：我們讀過的，知識留存率是10%。
我和面試者之間還經常會發(fā)生這樣的對話：
我：這個思路/技術選型是誰提出來的？
Ta：技術經理/領導/項目經理……
我：有沒有比較過其他實現(xiàn)思路？請講一下各自的優(yōu)缺點。
Ta：領導讓這么干的，所以沒比較過……
針對某一個課題，深入思考，多方調研，做試驗證明，很多工程師可能今生僅此一次：他大學畢業(yè)時做畢業(yè)論文的那次…………
如果長期滿足于東點點，西點點，今天可能是 Webpack、npm、Gulp，明天可能是 Spark、機器學習、流式計算，假設你過目不忘，知識的廣度倒是有了，但缺乏深度，長此以往，可能徹底毀掉了深度思考的能力。
所以，我們要“訓練”，強制性要求你從定義問題開始，訓練自己主動搜索、主動鏈接、主動構建知識、主動試驗、有始有終的能力。
定義問題
首先我們提出的問題，它必須是有重要意義、急需結果、目標是商用，但可能沒有現(xiàn)成的、確定的解決方案，同時這個問題必須能夠給整個團隊創(chuàng)造學習機會，提供發(fā)展個人和組織技能的機會。
那么通過講述我們看到了什么，想解決什么，通過你我不斷的思考和討論，直到你能清晰地抽象出一個明確具體的問題——這個時候，問題其實已經解決了一半。
舉例。
我們的平臺由數(shù)以百計的形形色色分布式服務構成，每一個請求一路走來，會經過多個業(yè)務系統(tǒng)并留下足跡，并產生對各種 Cache 或 DB 的訪問。作為訪問入口的 App 開發(fā)部門首當其沖會接到用戶投訴，然而請求會被隨機分配到集群的各個節(jié)點，所以找到對應的日志片段，理清調用關系，找到在哪里斷的，成為一個令人生畏的工作。
如何解決？前提是先定義出一個好問題。
拿“分布式系統(tǒng)”、“集群”、“日志”、“排查”等等關鍵字，去搜索，去看各種頂級團隊的博客，去看各種架構師演講資料，終于把問題聚焦于“分布式跟蹤（Distributed Tracing）”這個命題。
于是，問題被抽象為一個 Topic：
如何實現(xiàn)分布式跟蹤：追蹤每個請求的完整調用鏈路，收集調用鏈路上每個服務的調用參數(shù)和異常堆棧，統(tǒng)計每個服務的性能數(shù)據(jù)；可視化調用鏈，可視化服務質量。
主動構建知識
曾經看到過這么一句話：
只能不斷地學習基礎知識以及和這個技術（問題）關聯(lián)的知識，就像 Wikipeida 一樣，當你進入一個詞條的時候，就會伴隨一堆新詞條，于是，當多年后，我看到 “知識廣度是深度的副產品”這句話時，簡直就是說到我的心里去了。
仍以上面的例子舉例。
確定了分布式跟蹤的大方向之后，我們可以收集整理出各個公司在這個 Topic 上的實踐，Google的Dapper，淘寶的鷹眼，Twitter的ZipKin，京東商城的Hydra，eBay的Centralized Activity Logging (CAL)，大眾點評網的CAT。
接下來我們還可以整理出它們的架構思路和優(yōu)缺點，我們可以發(fā)現(xiàn)有的解決方案對工程侵入太重，給開發(fā)者造成了額外的負擔，有的解決方案依賴于該公司特有的、閉源的技術體系。
主動做試驗
怎么設計試驗，通過什么數(shù)據(jù)，打算證明什么，這也是一種能力。
舉例。
在實現(xiàn)實時數(shù)據(jù)大屏的時候，我們的一位工程師在 MySQL+Canal 后接入分布式消息隊列時，試驗了 Kafka 和 RocketMQ，目的是，第一求證能否確保嚴格的消息順序，這是數(shù)據(jù)庫變更訂閱希望看到的，第二做一下壓力測試，比較一下二者的性能。
有始有終
我這里說的有始有終，包含幾個意思：
畢竟這是一個商業(yè)應用，是要上線的，前前后后都要考慮清楚。我們考慮哪些點？首要的就是監(jiān)控報警。其次是線上數(shù)據(jù)如何遷移，線上應用如何接入。再次是性能。
公開分享你的所思所得，不僅做，還要寫下來，還要說出來。你一定要輸出你在這個問題上構建的知識結構，幫助自己，幫助大家，共同進步。
如是重復再重復，訓練再訓練，不妨試試看遵循 70-20-10 的學習法則：70%的學習時間放在針對現(xiàn)實生活和工作中遇到的任務、問題解決，20%的學習時間放在人與人之間正式的、非正式的反饋、輔導，10%的時間學習知識和信息（可能是碎片化的學習，也可能是讀書）。
這樣可能像把你裝進一個沙袋里吊起來，從四面八方用狼牙棒打你，酣暢淋漓。
-EOF-
贈圖一枚： 這棵樹長得很程序員?
?RT 王大神仙：你是開發(fā)，她是產品，你跟他PK了一天需求，她需求有了，你的代碼呢？
?
轉載于:https://www.cnblogs.com/zhengyun_ustc/p/topicStudy.html
總結
以上是生活随笔為你收集整理的有些事儿，工程师可能今生仅此一次的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： HDU5900 QSC and Mast
- 下一篇： 继 承（面向对象特征之二）