回顧我的職業(yè)生涯，我曾自己單槍匹馬地干過，也和一些特別有才能的人一起共事過，曾解決過一些非常嚴(yán)重的技術(shù)難題，也見識過一些鼎鼎大名的技術(shù)公司。近期我和我的團(tuán)隊(duì)偶然聊起我的這些經(jīng)歷，談?wù)摰某晒俏覀冊诰幋a時應(yīng)該知道一些原則。這不是規(guī)矩，也不是指導(dǎo)方針。它們只是我在編寫和運(yùn)行代碼時總結(jié)出來的一些需要注意的原則。

[[121445]]

1. 偏執(zhí)

這一點(diǎn)與我而言幾乎是天生的。我?guī)缀跏强孔詫W(xué)才成為了程序員。

我從不相信電腦，也不相信我剛剛修復(fù)的 bug 真的已經(jīng)修復(fù)好了，總之我不相信任何東西。我甚至連自己都不相信。除非多次檢驗(yàn)之后，我才會相信我已經(jīng)如我所愿地理解了問題。

偏執(zhí)是我的諍友，而且我認(rèn)為它也應(yīng)該成為我們每一個工程師的“左膀右臂”。我們要偏執(zhí)的是，應(yīng)該總是想著從另一種方式來證實(shí)假設(shè)，或者從另一個角度去看我們遺漏了什么。雖然很多時候這顯得很雞肋，但是有時候它能發(fā)揮至關(guān)重要的作用 。

2. 不要欺騙電腦

換言之就是“避免抽象漏洞”（注：抽象泄漏是指任何試圖減少或隱藏復(fù)雜性的抽象，其實(shí)并不能完全屏蔽細(xì)節(jié)，試圖被隱藏的復(fù)雜細(xì)節(jié)總是可能會泄漏出來）。系統(tǒng)該怎么用就怎么用，不要別出心裁自創(chuàng)用法。不要指望會出現(xiàn)什么奇跡。

如果系統(tǒng)使用規(guī)模超過當(dāng)前的三倍，那么就得考慮重新設(shè)計。

電腦是最誠實(shí)的孩子，如果你欺騙了它，它絕對會狠狠地反咬一口。

3. 簡單就好

我們喜歡創(chuàng)建一些新事物、解決一些疑難雜癥。這也是為什么我們干這一行的原因。但是很多時候，我們發(fā)現(xiàn)某個問題可以解決，卻并不意味著現(xiàn)在就是解決它的好時機(jī)。

我總是覺得自己是個愛自找麻煩的程序員——我喜歡干凈簡單易于理解的設(shè)計。別以為這很容易，相反這是一個難度不小的挑戰(zhàn)——以一種復(fù)雜的方式解決問題誰都能辦到，但是只有優(yōu)秀的程序員才能用一種既簡單又易于理解的方式解決問題。特別是要真正直截了當(dāng)?shù)厮伎汲鰡栴}的關(guān)鍵就更是難上加難了。

理解是重點(diǎn)，要知道程序員大部分時間是在維護(hù)代碼，而不是寫代碼。

4. 優(yōu)化***戒律就是不要優(yōu)化

這一點(diǎn)來自于 John Bentley 所著的經(jīng)典書籍《編程珠璣》。（它旨在幫助我們像一個經(jīng)驗(yàn)豐富的程序員一樣思考。雖然已經(jīng)發(fā)行了好多年，但是上面的很多經(jīng)驗(yàn)教訓(xùn)仍然適用于當(dāng)今社會。）

優(yōu)化可以采取多種形式：速度、后驗(yàn)形式、潛在規(guī)模、可能用途，等等。

問題在于，大多數(shù)的優(yōu)化最終是沒人用的，而且從定義上看，優(yōu)化或多或少會使得設(shè)計更加復(fù)雜。所以，優(yōu)化的***戒律就是不要優(yōu)化，除非你完全理解整個問題。（他的第二戒律依然是：“不要優(yōu)化”，意即即使你理解了，但是除非你真的需要才能去優(yōu)化。）

5. 不要僅僅修復(fù) bug；要修復(fù)所有可能發(fā)生 bug 的地方

對于自己犯的錯誤，沒必要耿耿于懷。每個人都討厭出現(xiàn) bug，我也是。

我討厭會讓我犯錯的系統(tǒng)。而且我真的非常非常討厭去修復(fù)同樣的 bug，所以為了避免這種情況，每當(dāng)我修復(fù)一個 bug 時，我就會思考以下問題：這種 bug 現(xiàn)在還有可能出現(xiàn)在哪里？以后又比較容易出現(xiàn)在什么地方？是什么原因造成了這種模式的 bug？我能不能一下子一網(wǎng)打盡呢？

6. 不斷地做問題假設(shè)

因?yàn)槲掖蟛糠謺r間都是在搞我自己的創(chuàng)業(yè)公司，所以我養(yǎng)成了一個不斷詢問自己的習(xí)慣“為什么要這么做？這能解決什么問題？有沒有更好的方法？有沒有什么更重要的事情是我還沒做到的？”

我們應(yīng)該一直保持這種態(tài)度，不斷地詢問自己這些假設(shè)情況。什么是真正需要解決的問題？是不是只要求解決效果而不必追究根本原因？解決方案完整嗎？完備嗎？值得嗎？

7. . 從長遠(yuǎn)角度思考。放慢腳步，才能跑得更快

這可能是最重要的一點(diǎn)了。作為工程師，我們享受于高效的工作效率：喜歡不斷地創(chuàng)建、創(chuàng)建、創(chuàng)建。但是如果我們不能用長遠(yuǎn)的角度看問題，只會作繭自縛，使得***越來越難構(gòu)建任何東西。

有時候，我們還沒理解問題就直接去寫代碼，***導(dǎo)致不得不放棄。有時候我們的方案雖然對局部問題很有療效，可卻能讓事情變得更糟或造成更嚴(yán)重的后果。有時候我們匆匆忙忙沒有完成設(shè)計，從而導(dǎo)致后期別人需要花更多的時間來修復(fù)。有時候我們只是懶得用正確的方式寫，直接就復(fù)制或者借鑒了別人的內(nèi)容，原因可能是因?yàn)槊χs項(xiàng)目進(jìn)度不想花時間去好好思考。……

上面這些情況舉不勝舉。也有人說，這可比我碰到的情況好多了，呵呵。但是我還是想重復(fù)一下——我們的目標(biāo)是建設(shè)最多***大的功能，擁有最廣泛的用戶。所以，目光要看得長遠(yuǎn)。

8. 關(guān)心自己的代碼

我想這一點(diǎn)沒必要過多解釋了吧。不過遺憾的是，現(xiàn)在有很多人時不時地將其拋之腦后。

為自己的工作驕傲！關(guān)心你自己寫的代碼！

如果我想偷懶抄近路，我就會告訴自己種瓜得瓜種豆得豆，現(xiàn)在偷懶將來可能會面對很多亂七八糟的代碼，***可憐的還是自己。

當(dāng)然你也不必極端——在谷歌公司我經(jīng)常開玩笑說其他的工程師對待代碼就像對自己的寵物一樣，而我和代碼之間的關(guān)系我更像是一個牧場主——務(wù)實(shí)，不感情用事。話雖然這樣說，但是碰到代碼不聽使喚的時候，我還是忍不住會發(fā)脾氣。

9. 成本、速度、正確率

這是軟件中的鐵三角關(guān)系，也是全世界軟件工程師孜孜以求的目標(biāo)。但是這不能成為我們裹足不前自滿自得的借口。

事實(shí)上，所謂程序員的優(yōu)秀和偉大之間的區(qū)別往往在于他們駕馭這個鐵三角的能力——偉大的程序員通常會想盡辦法盡可能地達(dá)到這三個目標(biāo)。我們都應(yīng)該努力成為偉大的程序員。

不過話說回來，魚與熊掌不可兼得，當(dāng)我們不得不摒棄這個鐵三角的時候，一定要明白我們要妥協(xié)什么，為什么而妥協(xié)，是否是當(dāng)前形勢下最正確的選擇。

10. ***，保持好奇心，不斷地學(xué)習(xí)

好吧，這可能看上去更像是職業(yè)建業(yè)。但是如果你沒有了好奇心，不愿意學(xué)習(xí)新鮮事物，不再關(guān)心新技術(shù)、新語言，那么你還干這一行干嘛呢？

上述編碼原則可能并不***，各位如有不同意見，歡迎指正，在下洗耳恭聽。

英文原文：Coding Principles Every Engineer Should Know

譯文鏈接：http://www.codeceo.com/article/10-coding-principles.html