Matt Rickard 是在谷歌從事 Kubernetes 開源工作的開發者，主要負責構建和維護 Kubernetes 開發者工具，例如 minikube 和 skaffold。此外他還作為 Kubeflow 項目的維護者負責機器學習管道方面的工作。

根據 Matt 的介紹，他已刻意投入了一萬小時用于訓練編程技能。Matt 擁有大約 15 年的編程經歷，目前在谷歌 Kubernetes 和私募股權公司 Blackstone 擔任專業軟件工程師。在此之前，Matt 在大學的大部分時間都在圖書館為自己的項目編寫程序。而在更早之前，他嘗試過各種各樣的事——在 RuneScape 上運行一個僵尸網絡、為 iPhone 編寫一個拉丁語翻譯應用、編寫自己的配置語言、創建一個網絡剪輯器，或者深度定制自己的桌面環境。

在這一萬小時的編程訓練中，Matt 最近的工作與分布式系統相關，但他曾經編寫過許多技術棧的代碼。編程語言方面使用過 PHP, JavaScript, Go, Ruby, Python, C#, Java, Swift，技術領域曾涉獵過前端、后端、移動端、內核、云、運維等。他還曾參與過像 Kubernetes 這樣的大型開源項目，并維護過子項目。

對于編程一萬小時的反思，Matt 強調這次的總結是純粹的關于編程的思考，不會討論技術管理、職業發展相關的話題。

以下就是 Matt 編程一萬小時后的 31 條反思：

• 閱讀源代碼常常會比在 Stack Overflow 上更快找到答案
• 大多數情況下，如果你正在做的事情無法在互聯網上找到答案，那么這通常意味著這個問題很難或者很重要，或者兩者都是
• 盡可能多地刪除代碼
• 語法糖通常是不好的
• 簡單往往是最難的
• 擁有各種各樣的工具，并知道該用哪些工具來完成工作
• 了解最常用的工具的內部結構，如 git 和 bash
• 為重復的工作流程構建自己專用的工具
• 從最好的資料中進行學習(這里 Matt 舉例稱他在學習 Go 時閱讀了標準庫)
• 如果代碼看起來很丑，那很可能是一個嚴重的錯誤
• 如果必須編寫不是文檔字符串 (docstring) 的注釋，則應該考慮對這段代碼進行重構
• 如果不了解所編寫的程序是如何在生產環境中運行的，那就說明不了解程序本身。優秀的工程師知道他們的程序在各種環境中是如何運行的
• 上面這條經驗對于構建管道也適用
• 謹慎使用他人的代碼
• 互聯網上找到的代碼大多數都很糟糕，有時候自己寫一個更好的版本會更容易
• 永遠不要直接依賴自己可以輕松重寫的小型庫，或本應很小的大型庫
• 知道什么時候該打破規則。對于“不要重復自己”這種規則，有時候重復比使用依賴要好
• 將代碼組織成模塊、包和函數很重要。了解 API 的邊界位置是一門藝術
• 大多數情況下應選擇最有效的工具，但也要選擇自己所知道的。Arch Linux 是現代開發者最高效的操作系統嗎?對我來說，是的，但對大多數人來說，可能不是
• 避免圈復雜度 (Cyclomatic complexity)
• 避免多層嵌套條件
• 正確命名變量，這也是一門藝術
• 雖然很少見，但有時報錯可能確實是編譯器的問題
• 謹慎使用深奧的語言特性，但在應該使用的時候還是要使用
• 技術的傳播并不均衡對等。例如，前端開發者可以從負責底層技術的工程師那里學到許多東西，云工程師可從 JavaScript 開發者身上學到用戶體驗和可用性方面的知識。但反過來卻未必成立
• 因此，不同類型的工程師看待世界的方式是不同的
• 部分程序員的效率是其他程序員的 10 倍
• 成為 10 倍程序員與 10 倍員工這兩者之間沒有相關性(或許是負相關)
• 好的 API 易于使用且難以誤用
• 配置七邊形(Matt 自創的術語)從硬編碼值開始，到環境變量、CLI Flag、配置文件、模板化配置文件、DSL、通用 bash 腳本，再到硬編碼值。開發者應了解這個七邊形中的各個位置。

• 所有抽象層都是可改變的。如果遇到了根本性的問題，有時答案就是往下再抽象一層，不要局限于表面

本文轉自OSCHINA

本文標題：編程一萬小時的反思

本文地址：https://www.oschina.net/news/154219/reflections-on-10000-hours-of-programming

資訊來源：https://matt-rickard.com/reflections-on-10-000-hours-of-programming/