如何成為更優(yōu)秀的工程師？

來自Heap（一家主要為企業(yè)提供用戶數(shù)據(jù)分析架構的企業(yè)）早期員工Michael Malis，就如何成為一名更加優(yōu)秀的工程師給出了自己的日常訓練方式：

讀論文；

學習一種新的工具；

讀書；

錄屏。

其中第四點比較有趣，大家感興趣可以直接跳到第四部分，看看他是如何具體實施的。以下為正文。

我的成為更好的工程師的方法是建立一套訓練體系。這套體系里有一些固定的練習，我每周都會進行。設計這套訓練體系有兩個非常明確的目標：

學習解決之前不會解決的問題；

學習如何更快更好的寫程序。

訓練計劃主要是由四個練習組成的，每一個都會幫助我向上面的兩個目標前進。這四個練習是：

讀論文；

學習新工具；

讀書；

寫程序的時候錄屏。然后回顧一下，看看能不能寫得更快。

下面我會詳細地介紹一下我是怎么做的。我想分享一些練習的細節(jié)，還有我從中獲得的收益。

讀論文

這項練習的目標是拓展CS相關的知識。在這之中我發(fā)現(xiàn)有兩方面直接收益。第一是一些論文可以改變我對一些固定問題的思考模式。舉個栗子，The Tail at Scale這篇論文驗證了反直覺的長尾延遲的本質(zhì)。

其中我認為比較有趣的是關于在大量機器上運行一個請求是怎樣影響延時的問題。作者研究了Google一項服務的實驗數(shù)據(jù)。這項服務將請求拆分，然后分發(fā)給不同的服務。

他們用數(shù)據(jù)評估了一下，將請求分發(fā)給100個服務的情況。作者發(fā)現(xiàn)，如果你測量從100項服務獲得回復的時間，一半以上的時間花費在等待最后五項服務的回復上。

這是因為最慢的5%的請求要比其他請求慢非常多。論文也給出了一些方法來降低長尾延遲。我發(fā)現(xiàn)這些方法，在我這邊的一些工作上也可以用。

第二個好處是我發(fā)現(xiàn)讀論文可以讓我融會貫通不同系統(tǒng)的知識。舉個栗子，Google的分布式數(shù)據(jù)庫Spanner。

Spanner用了很多不同的技術，比如Paxos、two phase commit、MVCC和predicted locks。通過閱讀相關論文，我就能建立對于這些不同的技術的理解。這可以讓我以一個整體來理解Spanner，并且和其他系統(tǒng)比較Spanner的利弊。

我讀的論文主要來自于以前讀過的論文的參考文獻或者Morning Paper的封面文章。Designing Data Intensive Applications這本書的參考文獻里也有很多值得一讀的論文。

學習新工具

解決問題最簡單辦法之一就是用一個解決這種問題的工具。這個練習就是選一個工具，然后學習一下它。

通常我的練習過程就是，安裝工具，練幾個教程，然后簡單看看手冊。我這么學過的工具范圍從bash指令比如JQ、Sed到分布式系統(tǒng)比如Kafka、Zookeeper。

學習bash指令讓我解決日常問題的效率提升了很多。類似的，學習不同的分布式系統(tǒng)可以讓我明白如何針對不同的問題運用不同的工具。

讀書

我用書來補充從論文里或者學習工具無法獲得的知識。我讀過的書主題范圍比較廣。比如最近讀過的：

Refactoring– 這本書讓我明白好的代碼是什么樣的，以及如何將不好的代碼轉化為好的代碼。

Getting Things Done– 這本書讓我明白如何安排工作的優(yōu)先級以及如何追蹤工作進展。它幫我建立了一套體系來確認優(yōu)先完成重要的工作。

The First Time Manager– 最近我剛好做了團隊管理員，需要協(xié)調(diào)不同的團隊一起工作，還要主持團隊會議。這本書有助于我理解管理的基本原理。

錄屏

這個訓練是我的最愛。這個練習也是對我解決問題改變最大的。運動員經(jīng)常會看自己的錄像來讓自己做的更好。

所以我決定也這么搞一下，來提升編程能力。我從自己的錄屏里學到的經(jīng)驗包括：

它可以幫助你在寫代碼的時候就測試代碼。這樣可以通過快速定位Bug來減少DEBUG方面消耗的時間。如果之前的代碼都沒有Bug，那Bug肯定是在你新寫的代碼里。

當DEBUG時，針對要DEBUG的對象專門添加函數(shù)是非常有必要的。舉個栗子，之前一個玩具的項目，我要寫一個LRU緩存。寫了個Bug，它不能清除正確的元素。這時我就可以快速地添加一個打印當前緩存狀態(tài)的函數(shù)來看一下是哪里出問題了。之后我就可以看一下緩存的期望狀態(tài)和現(xiàn)在實際情況的差別。這樣就可以讓我快速定位Bug。

在開始寫代碼之前，花五分鐘決定一下方向會非常的有效。這么做有兩點好處。首先是能夠確認方向是正確的。更重要的是，這樣可以強迫自己選擇單一的方向。因為看了我的錄像后，我發(fā)現(xiàn)我在選擇實現(xiàn)方向上經(jīng)常猶豫很長的時間，其實兩個方向都還OK。

所有這些經(jīng)驗現(xiàn)在回顧的時候都很明顯。但是在我看錄像，發(fā)現(xiàn)我在哪里花費大量時間之前都沒有能夠系統(tǒng)地將這些經(jīng)驗總結出來。

我做這項練習的步驟是：

記錄一些我寫程序的錄像?？梢允枪ぷ髦械?，也可以是在LeetCode這種刷題網(wǎng)站上刷題的時候。

十倍速看一遍錄像，并且記錄每個時刻我在做什么。

然后統(tǒng)計一下在大的類別上分別花費的時間。比如花了多少時間DEBUG，花了多少時間寫功能。

看看花時間最長的類目。然后仔細研究下為啥花費了這么長的時間。

提出一些能夠讓我節(jié)約時間的方法。有一些辦法可以讓我把代碼結構化，然后可以讓我少寫一些代碼或者更快找到Bug。

我強烈推薦寫代碼的時候錄屏。這是一種最簡單的不斷做一些小的改變來讓自己效率更高的方法。

這套訓練策略我堅持差不多一年了。感受到自己發(fā)生了很大的改變。學到了很多之前沒有學過的關于系統(tǒng)和工具的知識。

現(xiàn)在解決問題也要比之前快。希望你能考慮一下這些練習，然后自己也嘗試一下。