原作：Joseph
Ottinger， 來自近日的theServerSide，本文是譯文。
原作網址：http://www.theserverside.com/news/thread.tss?thread_id=42598
Empathy
Box在blog中介紹了編程應該注意的5個問題，這篇文章實際表述了編程時應引起注意的很重要的6個思想：
快速失敗；寫更少的代碼（不要讓自己重復）；程序是寫給人看的；做正確的事情；消減狀態；了解你的“創造”
（fail
fast, write less code (and don't repeat yourself), computer programs
are for people, do the right thing, reduce state, and know your
'stuff.'）
快速失敗：當程序出現問題時，產生大的、可見的、不可忽視的異常。以防止不明顯的bug一遍遍逃過QA的檢查。把隱藏在深處的問題暴露出來。
寫更少的代碼（似乎是理所當然的）：去除冗余，即把程序所要解決的問題展示得更加清晰、明了。
程序是寫給人看的：即“學識編程”（Literate
Programming），我們程序的讀者是其他的人而不是編譯器。我們知道c/java/lisp/haskell這些編程語言并不比簡單的匯編更加強大，之所以我們使用它們，是因為它們的表述更加清晰，更不容易范些低級的錯誤。沒有任何一個程序能做到只能用一種書寫，而不能用另一種，而且，這些語句，最終都要被翻譯成機器指令（有些在運行期，有些在編譯期，不過都不重要），如此說來，我們使用高級程序設計語言的唯一理由就是——和人進行交流。Don
Knuth寫下了這個想法，并把它命名為“Literate
Programming”，他還設計了一個叫WEB的系統，他的想法非常出色，但他的實現卻很糟糕。他的想法是：在程序中加入一篇說明程序是如何運行的的文章。
做正確的事情：實際編程去讓正確的程序去做正確的事情，而不是寫一個看似正常工作程序。
我知道最佳的解決方案，但需要改變許多東西。在我的經驗里，經常有讓你做錯誤事情的機會：計劃、經理、合作者，甚至是參與到項目中來的客戶，這些群體都想盡快看到你的可以工作的程序，他們并不關系你是如何寫這些程序的。但除了事實上寫這些程序的程序員外，沒有人知道，在編碼過程中所作的權衡、割舍。然后隱藏在代碼背后的問題就會像圣誕節的幽靈一樣以P0
bugs的形式出現（P0
bug:致命缺陷——譯者注）。最終，我不得不頂著上面巨大的壓力，帶給公司更多的花費。讓早就該做好的程序去做正確的事情。
消減狀態：即簡化代碼，尤其要注意并發的情況，這時會出現如：x.equals(x)這樣的奇怪代碼，而且在一些特殊的情況下會返回false,當然，這取決于x.equals(Object)是怎樣編碼的。
了解你的“創造”：正如可工作的解決方案總是你嘗試的最后一個解決方案一樣，無法診斷的bug總是存在于你還不了解的軟件層中。你必須去了解直接包裹在你代碼周圍的那些層——對于大多數程序員來說，這可能意味著要從操作系統開始。如果你從事底層編程，你很可能還要了解一些計算機體系結構。但這個觀點比直接找到隱藏的bug要大，主要用來清除那些不易解決的問題，一個了解操作系統內核的人，一定有能力去解決他們遇到的絕大多數問題。
@2008 楊一. 版權所有. 保留所有權利