大多數(shù)情況下，如果你正在做的事情無法在互聯(lián)網(wǎng)上找到答案，那么這通常意味著這個(gè)問題很難或者很重要，或者兩者都是

盡可能多地刪除代碼

語法糖通常是不好的

簡單往往是最難的

擁有各種各樣的工具，并知道該用哪些工具來完成工作

了解最常用的工具的內(nèi)部結(jié)構(gòu)，如 git 和 bash

為重復(fù)的工作流程構(gòu)建自己專用的工具

從最好的資料中進(jìn)行學(xué)習(xí)（這里 Matt 舉例稱他在學(xué)習(xí) Go 時(shí)閱讀了標(biāo)準(zhǔn)庫）

如果代碼看起來很丑，那很可能是一個(gè)嚴(yán)重的錯(cuò)誤

如果必須編寫不是文檔字符串 （docstring） 的注釋，則應(yīng)該考慮對這段代碼進(jìn)行重構(gòu)

如果不了解所編寫的程序是如何在生產(chǎn)環(huán)境中運(yùn)行的，那就說明不了解程序本身。優(yōu)秀的工程師知道他們的程序在各種環(huán)境中是如何運(yùn)行的

上面這條經(jīng)驗(yàn)對于構(gòu)建管道也適用

謹(jǐn)慎使用他人的代碼

互聯(lián)網(wǎng)上找到的代碼大多數(shù)都很糟糕，有時(shí)候自己寫一個(gè)更好的版本會更容易

永遠(yuǎn)不要直接依賴自己可以輕松重寫的小型庫，或本應(yīng)很小的大型庫

知道什么時(shí)候該打破規(guī)則。對于“不要重復(fù)自己”這種規(guī)則，有時(shí)候重復(fù)比使用依賴要好

將代碼組織成模塊、包和函數(shù)很重要。了解 API 的邊界位置是一門藝術(shù)

大多數(shù)情況下應(yīng)選擇最有效的工具，但也要選擇自己所知道的。Arch Linux 是現(xiàn)代開發(fā)者最高效的操作系統(tǒng)嗎？對我來說，是的，但對大多數(shù)人來說，可能不是

避免圈復(fù)雜度 （Cyclomatic complexity）

避免多層嵌套條件

正確命名變量，這也是一門藝術(shù)

雖然很少見，但有時(shí)報(bào)錯(cuò)可能確實(shí)是編譯器的問題

謹(jǐn)慎使用深?yuàn)W的語言特性，但在應(yīng)該使用的時(shí)候還是要使用

技術(shù)的傳播并不均衡對等。例如，前端開發(fā)者可以從負(fù)責(zé)底層技術(shù)的工程師那里學(xué)到許多東西，云工程師可從 JavaScript 開發(fā)者身上學(xué)到用戶體驗(yàn)和可用性方面的知識。但反過來卻未必成立

因此，不同類型的工程師看待世界的方式是不同的

部分程序員的效率是其他程序員的 10 倍

成為 10 倍程序員與 10 倍員工這兩者之間沒有相關(guān)性（或許是負(fù)相關(guān)）

好的 API 易于使用且難以誤用

配置七邊形（Matt 自創(chuàng)的術(shù)語）從硬編碼值開始，到環(huán)境變量、CLI Flag、配置文件、模板化配置文件、DSL、通用 bash 腳本，再到硬編碼值。開發(fā)者應(yīng)了解這個(gè)七邊形中的各個(gè)位置。

責(zé)任編輯：haq