有網友在 Quora 提問：如何把自己訓練得『程式設計速度又快，Bug 數量又少』？下面是 Glyn Williams 的回覆很精彩，4.5 k 贊。
三個程式設計師被要求穿過一片田地，到達另一側的房子。
菜鳥程式設計師目測了一下之間很短的距離，說：“不遠！我只要十分鐘。”
資深程式設計師看了一眼田地，想了一會，說：“我應該能在一天內過去。”菜鳥程式設計師很驚訝。
大神程式設計師看了一眼田地，說：“看起來要十分鐘，但我覺得十五分鐘應該夠了。” 資深程式設計師冷笑了一聲。
菜鳥程式設計師出發了，但只過了一會，地雷爆炸了，炸出了巨大的洞。這下他必須偏移預定的路線，原路返回，反覆嘗試穿過田地。最後他花了兩天到達目的地，到的時候顫顫發抖，還受了傷。
資深程式設計師一出發就匍匐前進，仔細地拍打地面，尋找地雷，只有在安全的時候才前進。他在一天的時間內小心謹慎地緩慢爬過了這片地，只觸發了幾個地雷。
大神程式設計師出發之後徑直穿過了田地，十分果斷。他只用了十分鐘就到了另一邊。
“你是怎麼做到的？”另外兩個人問道，“那些地雷怎麼沒有傷到你？”
“很簡單，”他回答道，“我最初就沒有埋地雷。”
當我們遇到我們（或其他人）給自己埋下的邏輯炸彈，程式設計會變得很困難。我們天天在編寫邏輯炸彈。它們就在地表下靜靜地待著，等著爆炸。一旦爆炸，通常就帶來不可預測的嚴重後果。
隨著新的程式碼模組被加入到專案中，專案的複雜度會上升。這種上升不是線性的，而是呈某種指數形式。
程式設計師的精力是一種有限的資源，所以這種爆炸式增長的複雜度最終會淹沒程式設計師。你的大腦最終會不堪重負，這是一個轉折點。
這就是炸彈開始爆炸的時刻。有各種各樣的炸彈：在遍歷時修改陣列，陣列下標偶爾變成負數，另一個執行緒在你的函式執行的起點和終點中間改變物件的狀態。轟，轟，轟……
我認為最快捷可靠的程式設計需要培養一種避免這些問題的風格。
編寫明確表達行為的程式碼。選擇有意義、準確、無歧義的符號名字。嚴格執行命名方案，不要用不同的單詞描述同一個事物。
如果有，採用最簡單的解決方案。不要為速度優化，而是為可讀性和透明度優化。
如果你在最初編寫程式碼時沒有注意可重用性，不要欺騙自己相信程式碼可以很神奇地被重用。相反，應該從一種情形著手，保持程式碼的具體性。如果值得修改程式碼讓它一般化，那麼應該做好徹底重寫的準備。
William Emmanuel Yu 的回覆：（5.5k 贊）
|
1 2 |
for (;;) practice(); |