程序員如何作到『編程速度又快，Bug 數量又少』？

有網友在 Quora 提問：如何把本身訓練得『編程速度又快，Bug 數量又少』？下面是 Glyn Williams 的回覆很精彩，4.5 k 贊。
 

三個程序員被要求穿過一片田地，到達另外一側的房子。
 

菜鳥程序員目測了一下之間很短的距離，說：「不遠！我只要十分鐘。」
 

資深程序員看了一眼田地，想了一會，說：「我應該能在一天內過去。」菜鳥程序員很驚訝。
 

大神程序員看了一眼田地，說：「看起來要十分鐘，但我以爲十五分鐘應該夠了。」 資深程序員冷笑了一聲。
 

菜鳥程序員出發了，但只過了一會，地雷爆炸了，炸出了巨大的洞。這下他必須偏移預約的路線，原路返回，反覆嘗試穿過田地。最後他花了兩天到達目的地，到的時候顫顫發抖，還受了傷。
 

資深程序員一出發就匍匐前進，仔細地拍打地面，尋找地雷，只有在安全的時候才前進。他在一天的時間內當心謹慎地緩慢爬過了這片地，只觸發了幾個地雷。
 

大神程序員出發以後徑直穿過了田地，十分果斷。他只用了十分鐘就到了另外一邊。
 

「你是怎麼作到的？」另外兩我的問道，「那些地雷怎麼沒有傷到你？」
 

「很簡單，」他回答道，「我最初就沒有埋地雷。」
 

當咱們遇到咱們（或其餘人）給本身埋下的邏輯炸彈，編程會變得很困難。咱們每天在編寫邏輯炸彈。它們就在地表下靜靜地待着，等着爆炸。一旦爆炸，一般就帶來不可預測的嚴重後果。
 

隨着新的代碼模塊被加入到項目中，項目的複雜度會上升。這種上升不是線性的，而是呈某種指數形式。
 

程序員的精力是一種有限的資源，因此這種爆炸式增加的複雜度最終會淹沒程序員。你的大腦最終會不堪重負，這是一個轉折點。
 

這就是炸彈開始爆炸的時刻。有各類各樣的炸彈：在遍歷時修改數組，數組下標偶爾變成負數，另外一個線程在你的函數執行的起點和終點中間改變對象的狀態。轟，轟，轟……
 

我認爲最快捷可靠的程序設計須要培養一種避免這些問題的風格。
 

編寫明確表達行爲的代碼。選擇有意義、準確、無歧義的符號名字。嚴格執行命名方案，不要用不一樣的單詞描述同一個事物。
 

若是有，採用最簡單的解決方案。不要爲速度優化，而是爲可讀性和透明度優化。
 

若是你在最初編寫代碼時沒有注意可重用性，不要欺騙本身相信代碼能夠很神奇地被重用。相反，應該從一種情形着手，保持代碼的具體性。若是值得修改代碼讓它通常化，那麼應該作好完全重寫的準備。

原文：http://www.php100.com/html/it/chengxuyuan/2015/0214/8646.html