如何成為更好的程式設計師
最近在我的社交圈子裡出現了關於“更為更好的程式設計師”的方法的討論。基於這場討論，我決定與大家分享一下自己的更為更好的程式設計師的方法。我希望大家知道，我發現的方法經實踐證明是有用的，所以大家也可以將它們用到自己的生活中。
我的改進的方法是圍繞訓練計劃建立的，我每週都有一套特定的“練習”，我在設計訓練計劃時考慮了兩個明確的目標：
- 學習怎麼解決我以前不會解決的問題
- 學習怎麼將程式寫的又快又好
我的訓練路線一直包含四個不同的練習，其中每一個都能幫助我達到上面所描述的兩個
目標。這四個練習如下：
- 讀一篇論文
- 學習一種新的工具
- 讀一本書的幾個章節
- 在寫程式的時候錄製螢幕，然後回顧所錄的視訊，思考如何能夠將程式寫的更快
在這裡，我再深入一些解釋下每個練習。我想分享下每個練習是如何起作用的細節和我通過每一個練習獲得的益處。
讀一篇論文
本練習旨在擴充套件我對電腦科學的瞭解，我發現閱讀論文有兩個最直接的好處。第一個好處是有些論文改變了我對一些問題的思考模式，一個很好的例子是《The Tail at Scale》，這篇論文研究了長尾延遲的反直覺性。
我從這篇論文中學到的一個有趣的教訓是在多臺機器上執行一個請求是如何影響延遲的。作者觀察了Google服務的經驗資料，他們使用這些資料來估算如果你在100個不同的服務中分發請求會發生什麼。作者發現，如果你測量從100個伺服器獲取響應所需要的時間，那麼將有一半的時間用於等待最後五個伺服器，這是因為最慢的5%的請求比其它請求慢的太多。本論文還提供了幾種減少尾部延遲的方法，我發現這些方法在我的工作中很有用。
通過閱讀論文，我發現的另一個好處是它們讓我整體性的瞭解不同的系統。例如，拿Google的分散式資料庫Spanner舉例，Spanner使用了許多不同的技術，像Paxos、兩階段提交、MVCC、predicate鎖等，通過閱讀論文我已經建立了對這些不同技術的理解。反過來，這也使我能夠將Spanner作為一個整體進行推理，將推斷Spanner與其它系統相比的權衡。
我發現我讀的大多數論文要麼是引用我讀過的文章要麼是引用早報上所述的文章。《Designing Data Intensive Applications》這本書也引用了許多值得閱讀的文章。
學習一種新的工具
一種解決問題最容易的方法是使用已經解決類似問題的現有工具。在本練習中，我選擇了一個工具並對它進行了解。通常我會在本地安裝這個工具，瀏覽一些教程和閱讀一些使用手冊。在過去，我學習過的工具包括從bash工具包（如jq或seq）到分散式系統（如Kafka或Zookeeper）.
學習bash工具可以幫助我解決許多常見任務，且比使用其它工具更快，如使用sed通常比使用程式設計更容易的進行簡單的文字處理。同樣，瞭解不同的分散式系統，能很容易的知道應該用什麼工具更好的解決遇到的各種不同的問題。通過這種練習方式，當我面對問題時我就知道自己應該用什麼工具了。
閱讀一本書的幾個章節
我通過書本來補充我不能夠從論文閱讀或學習工具的過程中獲取的知識，我讀過的書涉及了廣泛的主題。最近讀的書有:
- 《Refactoring》我發現讀這本書，是瞭解好程式碼應該是什麼樣子以及如何將壞程式碼轉換為好程式碼的方法。
- 《Getting Things Done》這書有助於確定事項的優先順序和追蹤記錄。它幫助我建立了一個系統，以確保我完成對我來說比較重要的事項。
- 《The First Time Manager》我最近成為了我們工作團隊的協調員，作為團隊協調員，我的主要工作是在需要的時候與其它團隊進行溝通。我也主導我們團隊的會議，我發現這本書非常有助於理解基本的管理原則。
錄製螢幕
這個練習是我最喜歡的，它最大程度的改變了我遇到問題的方式。通常運動員為了瞭解如何能做的更好會回顧自己的鏡頭，我也決定將這種方法應用到程式設計之中。通過錄制螢幕我總結出如下經驗教訓：
- 它有助於我在編寫程式碼時測試程式碼，這樣就可以減少花在定位bug位置的時間，從而減少除錯程式碼所需要的時間。如果你先前已經寫好的所有程式碼都是沒有問題的，那麼新的bug只可能會出現在最新寫好的程式碼中。
- 當除錯一個問題時，為了除錯而新增的功能通常是非常值得的。例如，我參與的一個玩具的問題是寫了一個URL快取，我並沒有正確的刪除結點元素導致出現了一個bug。此時通過新增一個列印快取狀態的函式，我能夠很快的確定哪裡出了問題。然後我可以看到快取中的預期行為與實際行為的不同之處，這讓我很快的定位到bug。
- 在編寫任何程式碼之前勞逸結合五分鐘時間確定一個要寫的方法是值得的。我發現這樣做有兩個好處：它有幫助確保我所寫的方法是正確的，更重要的是，它迫使我決定採用單一的方法。通過觀察自己的錄屏，我發花現自己在兩個不同的方法上來回改寫浪費了太多的時間，事實上，這兩個方法中的任何一個都能很好的達到目的。
回想起來，所有這些經驗教訓都是顯而易見的。直到錄屏後意識到自己在這些情況下花費的時間之前，我並不覺得這些情況都是有問題的。
我為這個練習採取的步驟是：
- 將一些問題錄製下來，可以是在工作中遇到的問題，也可以是程式設計挑戰網站（例如Leetcode）上的問題
- 以10倍的速度瀏覽視訊，並記錄每個申請時刻自己正在做什麼。
- 統計自己總共花費了多少時間在高階類別上，花了多少時間在除錯bug上？又花了多少時間在構建一些功能上？
- 檢視花費時間最多的類別，然後深入瞭解下實際所佔用的時間或哪些地方佔用了時間。
- 想出一個能夠節省時間的方法。通常有一些已經構建好可以複用的方法，這樣就可以讓我寫更少的程式碼或更容易的發現bug。
我強烈建議你建制螢幕。這是一種最容易幫助你做出最小改變而能在很大程度提高工作效率的方法。
在過去的一年裡我一直在執行這種訓練計劃。毫無疑問，我注意到了它帶來影響。這裡面有豐富的關於系統和工具的知識，足夠讓我不用再以其它方式進行開發，我也有了比以前更快的解決問題的能力。我希望你能考慮下這些訓練並將它們在自己身上實踐。
在未來，我打算開始分享我通過訓練計劃發現的一些東西，準備每做其中的一個練習時都寫一篇部落格。我將會分享自己在練習中學到的東西，感覺解說自己學到的東西不但能讓自己受益，還能夠為他人制作一些很好的學習資源。
英文原文：
https://malisper.me/my-approach-to-getting-dramatically-better-as-a-programmer/