你有沒有看過老式的黑白戰爭片?一個疲憊的士兵警覺地從灌木叢裏鑽出來。前面有一片空曠地那裏有地雷嗎?還是可以安全通過?沒有任何跡象表明那是雷區——沒有標記、沒有帶刺的鐵絲網、也沒有彈坑。士兵用他的刺刀戳了戳前方的地面，又趕緊縮回來，以爲會發生爆炸。沒有。於是他緊張地向前走了一會兒，刺刺這裏，戳戳那裏。最後。他確信這個地方是安全的，於是直起身來。驕傲地正步向前走去，結果卻被炸成了碎片。
士兵起初的探測沒有發現地雷，們這不過是僥倖。他由此得出了錯誤的結論——結果是災難性的。
傳統智慧認爲，項目一旦進入編碼階段，工作主要就是機械地把設計轉換爲可執行語句。我們認爲，這種態度是許多程序醜陋、低效、結構糟糕、不可維護和完全錯誤的最大一個原因。
編碼不是機械工作。如果它是，20世紀80年代初期人們寄下厚望的所有CASE工具早就取代了程序員。每一分鐘都需要做出決策——如果要讓所得的程序享有長久、無誤和富有生產力的“一生”，就必須對這些決策進行仔細的思考和判斷。
不主動思考他們的代碼的開發者是在靠巧合編程——代碼也許能工作，但卻沒有特別的理由說明它們爲何能工作。我們提倡要更積極地參與編碼過程。
儘管我們編寫的大部分代碼能夠快速執行，我們偶爾也會開發出一些算法，可能會讓最快的處理器都陷人困境。在”算法速率”中，我們將討論估算代碼的速度的方法，並且還給出一些提示，告訴你怎樣在存在問題發生之前就發現它們。
注重實效的程序員批判地思考所有代碼，包括我們自己的。我們不斷地在我們的程序和設計中看到改進的餘地。在“重構”中，我們將討論一些即使我們還處在項目中期，也能幫助我們修正現有代碼的技術。
只要你在製作代碼，你就應當記住，有一天你必須對其進行測試。要讓代碼易於測試，這樣你將増加它實際通過側試的可能性。
最後我們建議你小心那些替你編寫大量代碼的工具。除非你理解它們在做什麼。我們大多數人都能夠近乎自動地駕駛汽車——我們不用明確地命令我們的腳踩踏板，或是命令我們的手臂轉動方向盤——我們只是想“減速並右轉”。但是，可靠的好司機會不斷查看周圍的情況、檢查潛在的問題、並且讓自己在萬一發生意外時處在有利的位置上。編碼也是這樣——它也許在很大程度上只是例行公事，但保持警覺能夠很好地防止災難的發生。
作爲開發者，我們也工作在雷區裏。每天都有成百的陷阱在等着抓住我們。記住士兵的故事，我們應該警惕，不要得出錯誤的結論。我們應該避免靠巧合編程——依靠運氣和偶然的成功——而要深思熟慮地編程。