10,000 小時程式設計反思

一萬小時定律是作家Malcolm Gladwell在《異類》一書中指出的定律。「人們眼中的天才之所以卓越非凡，並非天資超人一等，而是付出了持續不斷的努力。要成為某個領域的專家，需要10000小時（1.1415525年），按比例計算就是：如果每天工作八個小時，一週工作五天，那麼成為一個領域的專家至少需要五年。

Matt Rickard 有15 年的程式設計經驗，曾在谷歌 Kubernetes 和私募股權公司 Blackstone 擔任專業軟體工程師。在此之前，他大學的大部分時間都在圖書館為自己的項目編寫程式，他曾經做過各種各樣的事情——在 RuneScape 上運行一個僵屍網路，為 iPhone 編寫一個拉丁語翻譯應用程式（這樣Matt Rickard可以在拉丁語考試中做得更好），編寫自己配置語言，創建一個網路剪輯器，或者讓我的桌面活躍起來。

Matt Rickard介紹自己最近的工作與分散式系統相關，他曾經編寫過許多關於技術棧的程式碼，使用過 PHP, JavaScript, Go, Ruby, Python, C#, Java, Swift等程式語言，涉獵過前端、後端、移動端、核心、雲、運維等技術領域。他還曾參與過像 Kubernetes 這樣的大型開源項目，並維護過子項目。

在這一萬小時的程式設計訓練中，Matt Rickard對程式設計產生31條思考。這裡只是對純編碼的思考，不會涉及到如何成為一名高階技術經理，如何在職場上獲得快速晉升等方面的建議，這些非常重要，但並不是本文的主題。

1. 尋找答案的最佳途徑是瀏覽原始碼，而不是網站上尋找；

2. 在許多情況下，您正在從事的工作在網際網路上沒有答案。意味著問題很困難或很重要，兩者兼而有之；

3. 儘可能多地刪除程式碼；（Delete as much code as you can）

4. 語法糖通常是不友好的；

5. 簡單也意味著困難；

6. 熟悉各種各樣的工具，並知道使用哪些工具來完成工作；

7. 瞭解最常用的內部結構，知道常用的內部程式碼協作工具，如 git 和 bash（可以擺脫大部分低質的 git rebase 或 merge）；

8. 為重複性的工作構建自動化工具；

9. 只從最好的資料中學習，Matt Rickard舉例學習Go語言時，閱讀了標準的Go語言標準庫；

10. 如果程式碼看起來很醜，那很可能是一個可怕的錯誤；

11. 如果編寫的不是文件字元串的註釋，需要思考應該對程式碼進行重構；

12. 編寫程式設計師要知其然知其所以然。據Matt Rickard的經驗，最好的工程師都會知曉程式在各個環境下的運行機制；

13. 上述規則也適用於構建Pipeline ；

14. 謹慎地使用他人的程式碼；

15. 網上的大部分程式碼都很糟糕，不一定適用於你，自己優化的版本可能會更好更容易；

16. 永遠不要直接依賴可以輕鬆重寫的小型庫，也不要直接依賴本應很小的大型庫；

17. 學會打破規則；

18. 將程式碼組織成模組、包和函數很重要；

19. 大多數時候需要選擇最有效的工具，但也要選擇你所熟悉的；

20. 避免圈複雜度；

21. 避免深度巢狀條件；

22. 正確命名變數，也是一門藝術；

23. 重視編譯器本身編譯錯誤；

24. 謹慎使用深奧的程式語言特性；

25. 技術的傳播並不均衡。例如，前端開發人員可以從低階工程師那裡學到很多東西（尤其是現在一切都已編譯），同樣，JavaScript 開發人員也可以教授雲工程師的 UX 和可用性功能；

26. 學會用不同的眼光與方式看待世界；

27. 有些程式設計師的效率是其他程式設計師的 10 倍；

28. 成為 10 倍程式設計師和 10 倍員工之間沒有相關性（可能是負面的）；

29. 好的 API 易於使用且難以誤用；

30. 配置週期從硬編碼值到環境變數、CLI 標誌、配置檔案、模板化配置檔案、DSL、通用 bash指令碼，再到硬編碼值。知道你在這個[七邊形能力]的配置中的位置；

來源於Matt Rickard部落格分享

31. 所有抽象層都是可延展的。如果遇到基本的問題，有時答案就是往下再抽象一層，不要侷限於表面。

參考文章連結：

https://matt-rickard.com/reflections-on-10-000-hours-of-programming/