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

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

讀論文；

學(xué)習(xí)一種新的工具；

讀書(shū)；

錄屏。

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

我的成為更好的工程師的方法是建立一套訓(xùn)練體系。這套體系里有一些固定的練習(xí)，我每周都會(huì)進(jìn)行。設(shè)計(jì)這套訓(xùn)練體系有兩個(gè)非常明確的目標(biāo)：

學(xué)習(xí)解決之前不會(huì)解決的問(wèn)題；

學(xué)習(xí)如何更快更好的寫(xiě)程序。

訓(xùn)練計(jì)劃主要是由四個(gè)練習(xí)組成的，每一個(gè)都會(huì)幫助我向上面的兩個(gè)目標(biāo)前進(jìn)。這四個(gè)練習(xí)是：

讀論文；

學(xué)習(xí)新工具；

讀書(shū)；

寫(xiě)程序的時(shí)候錄屏。然后回顧一下，看看能不能寫(xiě)得更快。

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

讀論文

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

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

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

這是因?yàn)樽盥?%的請(qǐng)求要比其他請(qǐng)求慢非常多。論文也給出了一些方法來(lái)降低長(zhǎng)尾延遲。我發(fā)現(xiàn)這些方法，在我這邊的一些工作上也可以用。

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

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

我讀的論文主要來(lái)自于以前讀過(guò)的論文的參考文獻(xiàn)或者M(jìn)orning Paper的封面文章。Designing Data Intensive Applications這本書(shū)的參考文獻(xiàn)里也有很多值得一讀的論文。

學(xué)習(xí)新工具

解決問(wèn)題最簡(jiǎn)單辦法之一就是用一個(gè)解決這種問(wèn)題的工具。這個(gè)練習(xí)就是選一個(gè)工具，然后學(xué)習(xí)一下它。

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

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

讀書(shū)

我用書(shū)來(lái)補(bǔ)充從論文里或者學(xué)習(xí)工具無(wú)法獲得的知識(shí)。我讀過(guò)的書(shū)主題范圍比較廣。比如最近讀過(guò)的：

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

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

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

錄屏

這個(gè)訓(xùn)練是我的最愛(ài)。這個(gè)練習(xí)也是對(duì)我解決問(wèn)題改變最大的。運(yùn)動(dòng)員經(jīng)常會(huì)看自己的錄像來(lái)讓自己做的更好。

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

它可以幫助你在寫(xiě)代碼的時(shí)候就測(cè)試代碼。這樣可以通過(guò)快速定位Bug來(lái)減少DEBUG方面消耗的時(shí)間。如果之前的代碼都沒(méi)有Bug，那Bug肯定是在你新寫(xiě)的代碼里。

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

在開(kāi)始寫(xiě)代碼之前，花五分鐘決定一下方向會(huì)非常的有效。這么做有兩點(diǎn)好處。首先是能夠確認(rèn)方向是正確的。更重要的是，這樣可以強(qiáng)迫自己選擇單一的方向。因?yàn)榭戳宋业匿浵窈?，我發(fā)現(xiàn)我在選擇實(shí)現(xiàn)方向上經(jīng)常猶豫很長(zhǎng)的時(shí)間，其實(shí)兩個(gè)方向都還OK。

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

我做這項(xiàng)練習(xí)的步驟是：

記錄一些我寫(xiě)程序的錄像?？梢允枪ぷ髦械模部梢允窃贚eetCode這種刷題網(wǎng)站上刷題的時(shí)候。

十倍速看一遍錄像，并且記錄每個(gè)時(shí)刻我在做什么。

然后統(tǒng)計(jì)一下在大的類別上分別花費(fèi)的時(shí)間。比如花了多少時(shí)間DEBUG，花了多少時(shí)間寫(xiě)功能。

看看花時(shí)間最長(zhǎng)的類目。然后仔細(xì)研究下為啥花費(fèi)了這么長(zhǎng)的時(shí)間。

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

我強(qiáng)烈推薦寫(xiě)代碼的時(shí)候錄屏。這是一種最簡(jiǎn)單的不斷做一些小的改變來(lái)讓自己效率更高的方法。

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

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