本文經授權轉自公眾號「ALFRED阿福」

責編 | 胡巍巍

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

1. 讀論文；
2. 學習一種新的工具；
3. 讀書；
4. 錄屏。

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

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

• 學習解決之前不會解決的問題；
• 學習如何更快更好的寫程序。

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

• 讀論文；
• 學習新工具；
• 讀書；
• 寫程序的時候錄屏。然後回顧一下，看看能不能寫得更快。

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

1.讀論文

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

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

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

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

第二個好處是我發現讀論文可以讓我融會貫通不同系統的知識。舉個栗子，Google的分散式資料庫Spanner。

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

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

2.學習新工具

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

通常我的練習過程就是，安裝工具，練幾個教程，然後簡單看看手冊。我這麼學過的工具範圍從bash指令比如JQ、Sed到分散式系統比如Kafka、Zookeeper。

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

3.讀書

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

• Refactoring

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

• Getting Things Done

  – 這本書讓我明白如何安排工作的優先順序以及如何追蹤工作進展。它幫我建立了一套體系來確認優先完成重要的工作。

• The First Time Manager

  – 最近我剛好做了團隊管理員，需要協調不同的團隊一起工作，還要主持團隊會議。這本書有助於我理解管理的基本原理。

4.錄屏

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

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

• 它可以幫助你在寫代碼的時候就測試代碼。這樣可以通過快速定位Bug來減少DEBUG方面消耗的時間。如果之前的代碼都沒有Bug，那Bug肯定是在你新寫的代碼里。
• 當DEBUG時，針對要DEBUG的對象專門添加函數是非常有必要的。舉個栗子，之前一個玩具的項目，我要寫一個LRU緩存。寫了個Bug，它不能清除正確的元素。這時我就可以快速地添加一個列印當前緩存狀態的函數來看一下是哪裡出問題了。之後我就可以看一下緩存的期望狀態和現在實際情況的差別。這樣就可以讓我快速定位Bug。
• 在開始寫代碼之前，花五分鐘決定一下方向會非常的有效。這麼做有兩點好處。首先是能夠確認方向是正確的。更重要的是，這樣可以強迫自己選擇單一的方向。因為看了我的錄像後，我發現我在選擇實現方向上經常猶豫很長的時間，其實兩個方向都還OK。

所有這些經驗現在回顧的時候都很明顯。但是在我看錄像，發現我在哪裡花費大量時間之前都沒有能夠系統地將這些經驗總結出來。

我做這項練習的步驟是：

1. 記錄一些我寫程序的錄像。可以是工作中的，也可以是在LeetCode這種刷題網站上刷題的時候。
2. 十倍速看一遍錄像，並且記錄每個時刻我在做什麼。
3. 然後統計一下在大的類別上分別花費的時間。比如花了多少時間DEBUG，花了多少時間寫功能。
4. 看看花時間最長的類目。然後仔細研究下為啥花費了這麼長的時間。
5. 提出一些能夠讓我節約時間的方法。有一些辦法可以讓我把代碼結構化，然後可以讓我少寫一些代碼或者更快找到Bug。

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

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

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

原文：https://malisper.me/my-approach-to-getting-dramatically-better-as-a-programmer

翻譯：阿福

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！