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

盡可能多地刪除代碼

語法糖通常是不好的

簡單往往是最難的

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

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

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

從最好的資料中進行學(xué)習(xí)（這里 Matt 舉例稱他在學(xué)習(xí) Go 時閱讀了標準庫）

如果代碼看起來很丑，那很可能是一個嚴重的錯誤

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

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

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

謹慎使用他人的代碼

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

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

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

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

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

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

避免多層嵌套條件

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

雖然很少見，但有時報錯可能確實是編譯器的問題

謹慎使用深奧的語言特性，但在應(yīng)該使用的時候還是要使用

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

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

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

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

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

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

責(zé)任編輯：haq