作者在twitter上發的一條短訊：
「在怨天尤人之前，我們應該先自我反省、努力把自身的問題解決了。」
12:22 pm –2012-5-30
你應該知道那種感覺。我們所有人都曾碰到過這樣的事情：你已經盯著**看了無數遍，但還是沒有發現任何問題。然而，有個故障或者錯誤始終揮之不去。於是你開始懷疑，一定是你開發程式所用的那台機器出了問題，也可能是作業系統的問題，或者是你使用的工具和庫出了問題。肯定是它們的原因！
然而，無論你多麼絕望，你都不要往那條路上走。沿著那條路下去就是「伏都」計算和靠運氣程式設計。說白了，就是愚蠢。
譯者注：伏都教（
voodoo
），又譯
「巫毒教
」，源於非洲西部，是糅合祖先崇拜、萬物有靈論、通靈術的原始宗教。
老是要處理一些困難的、捉摸不透的問題，這是一件令人絕望的事情，但是不要讓絕望領著你誤入歧途。作為一名謙遜的程式設計師，最基本的要求就是要有意識：你寫的**在任何時候出了問題，那一定都是你的錯。這個觀點在《程式設計師修煉之道：從小工到專家》一書中被巧妙地歸結為「select沒有問題」：
譯者注：
select
是用於i/o
多路轉接的乙個系統呼叫函式。
在大多數專案中，你所除錯的**裡常常混雜著這些東西：你和專案小組中的其他成員開發的應用**、第三方的產品（資料庫、鏈結器、圖形庫、特殊的通訊系統或者演算法等）以及平台環境（作業系統、系統庫和編譯器）。
作業系統、編譯器或者第三方產品出問題的可能性是有的——但是，這絕對不應該是你碰到問題後的第一反應。錯誤出現在正在開發的應用**中的可能性要大得多的多。通常情況下，假定應用程式錯誤地呼叫了庫函式要比假定庫本身有問題更有效益。即便問題出在第三方，你還是必須徹底排除自身**的問題，然後再提交錯誤報告。
我們曾經做過乙個專案，專案中的一位高階工程師確信solaris上的select系統呼叫出了問題。無數次的勸說和邏輯分析都不能改變他的主意（事實上，所有其他的網路應用程式在同樣的機器上都能正常工作，但他仍然固執己見）。他花了好幾個星期來做變通方案，但是因為一些詭異的原因，這些方案似乎都行不通。他最終不得不坐下來，仔細地閱讀關於select的文件。然後，他找到了真正的問題，並且在幾分鐘內就把問題解決了。如今，一旦我們當中有人開始為了乙個很可能是我們自己造成的錯誤而責怪系統時，我們會用「select有問題」這個短語作為善意的提醒。
譯者注：
solaris
是乙個類似於
unix
的作業系統，最初由
sun microsystems
公司開發。早期的
solaris
主要針對伺服器以及企業應用領域，在
sun的高效能工作站上有廣泛的應用。
**產權的另一面是**責任。無論你的軟體出現什麼樣的問題——甚至最開始出錯的地方根本就不是你的**——你也應該總是假定問題出在你的**裡，並且根據這個假設採取行動。如果你想讓世界人民接受你的軟體，那你就要為它的故障承擔全責。儘管——從嚴格意義上來說——你並不是非這麼做不可。只有這樣，你才能贏得尊敬和信用。如果你不斷地把問題推卸到其他人、其他公司或者其他的源頭上，你是無論如何也得不到尊敬和信用的。
從統計學的角度來說，軟體中的故障或者錯誤一般都是人為的，例外的可能性鳳毛麟角。我想你已經明白了這一點。在《**大全》（《codecomplete》）一書中，steve mcconnell引用了兩個研究來證明這個觀點：
在2023年和2023年進行的兩次研究發現，在所有報告的錯誤中，大約有95%是由程式設計師造成的，2%是由系統軟體（編譯器和作業系統）引起的，2%是由其他軟體引起的，1%是由硬體造成的。跟2023年代和2023年代相比，現在的系統軟體和開發工具的使用人群要大得多，所以我猜想，現如今應該有更高比例的錯誤是由程式設計師的過失造成的。
不管你的軟體出了什麼問題，請你負起責任來吧！從你的**開始，深入進去，逐步向外調查，直到你找到確鑿的證據證明問題之所在。如果問題出在你無法控制的**上，你不但學會了必要的故障排除和診斷技巧，同時還獲得了用來支援你指控別人的審計證據。當然，和你聳聳肩膀簡單地把問題歸責於作業系統、工具或者應用框架相比，這樣花費的工夫要多得多——但是這也會逐步形成信任和尊敬的感覺，而這種感覺是你通過指責他人和逃避不可能得到的。
如果你真的渴望做一名謙遜的程式設計師，在你碰到問題的時候，你就應該很淡定地說：「嘿，這是我的錯——讓我把它弄個水落石出。」
95 的bug是由程式設計師造成的
作者在twitter上發的一條短訊 在怨天尤人之前，我們應該先自我反省 努力把自身的問題解決了。12 22 pm 2012 5 30 你應該知道那種感覺。我們所有人都曾碰到過這樣的事情 你已經盯著 看了無數遍，但還是沒有發現任何問題。然而，有個故障或者錯誤始終揮之不去。於是你開始懷疑，一定是你開發程...
程式設計師的bug修復寶典
bug,又名程式缺陷或者程式漏洞,是每個程式設計師每天都迴避不了的東西。程式設計師對bug的感情可謂是五味雜陳 一方面bug非常可惡，尤其是一些偶現的bug，它強大到可以摧毀乙個優秀程式設計師的意志 另一方面很多bug又是程式設計師自己親手寫下的，無奈之餘只能自嘲一句 不寫bug我們就要失業了！作為...
那些讓程式設計師目瞪口呆的Bug
1 麻省理工 只能發500英里的郵件 該bug發生於麻省理工，當時其系統管理員接到統計系主任的求助 主任在 中說 咱們的郵件系統無法傳送距離500英里以外的地方，準確地說好像是520英里。此時的系統管理員內心是 毫無波瀾 的，嗯！然後，他開始了漫長且苦逼的測試，最後發現郵件伺服器作業系統 sunos...