Matt Rickard 是在谷歌從事 Kubernetes 開源工作的開發(fā)者，主要負(fù)責(zé)構(gòu)建和維護(hù) Kubernetes 開發(fā)者工具，例如 minikube 和 skaffold。此外他還作為 Kubeflow 項(xiàng)目的維護(hù)者負(fù)責(zé)機(jī)器學(xué)習(xí)管道方面的工作。

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

在這一萬(wàn)小時(shí)的編程訓(xùn)練中，Matt 最近的工作與分布式系統(tǒng)相關(guān)，但他曾經(jīng)編寫過許多技術(shù)棧的代碼。編程語(yǔ)言方面使用過 PHP, JavaScript, Go, Ruby, Python, C#, Java, Swift，技術(shù)領(lǐng)域曾涉獵過前端、后端、移動(dòng)端、內(nèi)核、云、運(yùn)維等。他還曾參與過像 Kubernetes 這樣的大型開源項(xiàng)目，并維護(hù)過子項(xiàng)目。

對(duì)于編程一萬(wàn)小時(shí)的反思，Matt 強(qiáng)調(diào)這次的總結(jié)是純粹的關(guān)于編程的思考，不會(huì)討論技術(shù)管理、職業(yè)發(fā)展相關(guān)的話題。

以下就是 Matt 編程一萬(wàn)小時(shí)后的 31 條反思：

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

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

本文轉(zhuǎn)自O(shè)SCHINA

本文標(biāo)題：編程一萬(wàn)小時(shí)的反思

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

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