作者在Twitter上發(fā)的一條短訊：

“在怨天尤人之前，我們應(yīng)該先自我反省、努力把自身的問題解決了。”

12:22 PM –2012-5-30

[[108733]]

你應(yīng)該知道那種感覺。我們所有人都曾碰到過這樣的事情：你已經(jīng)盯著代碼看了無數(shù)遍，但還是沒有發(fā)現(xiàn)任何問題。然而，有個(gè)故障或者錯(cuò)誤始終揮之不去。 于是你開始懷疑，一定是你開發(fā)程序所用的那臺(tái)機(jī)器出了問題，也可能是操作系統(tǒng)的問題，或者是你使用的工具和庫(kù)出了問題?？隙ㄊ撬鼈兊脑?！

然而，無論你多么絕望，你都不要往那條路上走。沿著那條路下去就是“伏都”計(jì)算和靠運(yùn)氣編程。說白了，就是愚蠢。

譯者注：伏都教（voodoo），又譯“巫毒教”，源于非洲西部，是糅合祖先崇拜、萬物有靈論、通靈術(shù)的原始宗教。

老是要處理一些困難的、捉摸不透的問題，這是一件令人絕望的事情，但是不要讓絕望領(lǐng)著你誤入歧途。作為一名謙遜的程序員，最基本的要求就是要有意識(shí)：你寫的代碼在任何時(shí)候出了問題，那一定都是你的錯(cuò)。這個(gè)觀點(diǎn)在《程序員修煉之道：從小工到專家》一書中被巧妙地歸結(jié)為“select沒有問題”：

譯者注：select是用于I/O多路轉(zhuǎn)接的一個(gè)系統(tǒng)調(diào)用函數(shù)。

在大多數(shù)項(xiàng)目中，你所調(diào)試的代碼里常常混雜著這些東西：你和項(xiàng)目小組中的其他成員開發(fā)的應(yīng)用代碼、第三方的產(chǎn)品（數(shù)據(jù)庫(kù)、鏈接器、圖形庫(kù)、特殊的通信系統(tǒng)或者算法等）以及平臺(tái)環(huán)境（操作系統(tǒng)、系統(tǒng)庫(kù)和編譯器）。

操作系統(tǒng)、編譯器或者第三方產(chǎn)品出問題的可能性是有的——但是，這絕對(duì)不應(yīng)該是你碰到問題后的***反應(yīng)。錯(cuò)誤出現(xiàn)在正在開發(fā)的應(yīng)用代碼中的可能性要 大得多的多。通常情況下，假定應(yīng)用程序錯(cuò)誤地調(diào)用了庫(kù)函數(shù)要比假定庫(kù)本身有問題更有效益。即便問題出在第三方，你還是必須徹底排除自身代碼的問題，然后再 提交錯(cuò)誤報(bào)告。

我們?cè)?jīng)做過一個(gè)項(xiàng)目，項(xiàng)目中的一位高級(jí)工程師確信Solaris上的select系統(tǒng)調(diào)用出了問題。無數(shù)次的勸說和邏輯分析都不能改變他的主意 （事實(shí)上，所有其他的網(wǎng)絡(luò)應(yīng)用程序在同樣的機(jī)器上都能正常工作，但他仍然固執(zhí)己見）。他花了好幾個(gè)星期來做變通方案，但是因?yàn)橐恍┰幃惖脑?，這些方案似 乎都行不通。他最終不得不坐下來，仔細(xì)地閱讀關(guān)于select的文檔。然后，他找到了真正的問題，并且在幾分鐘內(nèi)就把問題解決了。如今，一旦我們當(dāng)中有人 開始為了一個(gè)很可能是我們自己造成的錯(cuò)誤而責(zé)怪系統(tǒng)時(shí)，我們會(huì)用“select有問題”這個(gè)短語(yǔ)作為善意的提醒。

譯者注：Solaris是一個(gè)類似于Unix的操作系統(tǒng)，最初由Sun Microsystems公司開發(fā)。早期的Solaris主要針對(duì)服務(wù)器以及企業(yè)應(yīng)用領(lǐng)域，在Sun的高性能工作站上有廣泛的應(yīng)用。

代碼產(chǎn)權(quán)的另一面是代碼責(zé)任。無論你的軟件出現(xiàn)什么樣的問題——甚至最開始出錯(cuò)的地方根本就不是你的代碼——你也應(yīng)該總是假定問題出在你的代碼里， 并且根據(jù)這個(gè)假設(shè)采取行動(dòng)。如果你想讓世界人民接受你的軟件，那你就要為它的故障承擔(dān)全責(zé)。盡管——從嚴(yán)格意義上來說——你并不是非這么做不可。只有這 樣，你才能贏得尊敬和信用。如果你不斷地把問題推卸到其他人、其他公司或者其他的源頭上，你是無論如何也得不到尊敬和信用的。

從統(tǒng)計(jì)學(xué)的角度來說，軟件中的故障或者錯(cuò)誤一般都是人為的，例外的可能性鳳毛麟角。我想你已經(jīng)明白了這一點(diǎn)。在《代碼大全》（《CodeComplete》）一書中，Steve McConnell引用了兩個(gè)研究來證明這個(gè)觀點(diǎn)：

在1973年和1984年進(jìn)行的兩次研究發(fā)現(xiàn)，在所有報(bào)告的錯(cuò)誤中，大約有95%是由程序員造成的，2%是由系統(tǒng)軟件（編譯器和操作系統(tǒng)）引起 的，2%是由其他軟件引起的，1%是由硬件造成的。跟1970年代和1980年代相比，現(xiàn)在的系統(tǒng)軟件和開發(fā)工具的使用人群要大得多，所以我猜想，現(xiàn)如今 應(yīng)該有更高比例的錯(cuò)誤是由程序員的過失造成的。

不管你的軟件出了什么問題，請(qǐng)你負(fù)起責(zé)任來吧！從你的代碼開始，深入進(jìn)去，逐步向外調(diào)查，直到你找到確鑿的證據(jù)證明問題之所在。如果問題出在你無法 控制的代碼上，你不但學(xué)會(huì)了必要的故障排除和診斷技巧，同時(shí)還獲得了用來支持你指控別人的審計(jì)證據(jù)。當(dāng)然，和你聳聳肩膀簡(jiǎn)單地把問題歸責(zé)于操作系統(tǒng)、工具 或者應(yīng)用框架相比，這樣花費(fèi)的工夫要多得多——但是這也會(huì)逐步形成信任和尊敬的感覺，而這種感覺是你通過指責(zé)他人和逃避不可能得到的。

如果你真的渴望做一名謙遜的程序員，在你碰到問題的時(shí)候，你就應(yīng)該很淡定地說：“嘿，這是我的錯(cuò)——讓我把它弄個(gè)水落石出。”

原文鏈接：http://www.codinghorror.com/blog/2008/03/the-first-rule-of-programming-its-always-your-fault.html

譯文鏈接：http://blog.csdn.net/happydeer/article/details/18815345