程序員如何做到「編程速度又快，Bug 數量又少」？

來源：綜合整理自php、演算法愛好者

最近看到一個Quora中的關於如何做到編程速度快，同時Bug 數量少的回答，Glyn Williams等的回答非常精彩，網友紛紛點贊。譯文引用自伯樂在線：

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

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

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

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

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

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

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

「你是怎麼做到的?」另外兩個人問道，「那些地雷怎麼沒有傷到你?」

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

地雷從何而來?

與大神一起工作的時候就是這種感覺，也是我的第一印象「代碼整潔而且沒有地雷」。可是反過來想，為什麼有的人就是習慣於埋雷呢?難道看不到後果嗎?

以下為Glyn Williams 的回復，4.5 k 贊。

事實上，隨著新的代碼模塊被加入到項目中，項目的複雜度會以某種指數形式上升，然而程序員精力有限，這些自己（或其他人）埋下的邏輯炸彈會讓你的大腦最終會不堪重負，最終會淹沒程序員。

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

所以，我認為最快捷可靠的程序設計還需要培養一種避免這些問題的風格。

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

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

如果你在最初編寫代碼時沒有注意可重用性，不要欺騙自己相信代碼可以很神奇地被重用。相反，應該從一種情形著手，保持代碼的具體性。如果值得修改代碼讓它一般化，那麼應該做好徹底重寫的準備。

以下為William Emmanuel Yu 的回復：（5.5k 贊）

再深一層來講，沒人願意給自己埋地雷，主要還是沒有對習慣引起重視。培養起好的編程習慣是非常重要的。編程中的壞習慣，是很多程序員上升的天花板，十年原 地踏步的原因。

想要寫出好代碼，一定要常常問自己「我還能做的更好嗎?」(好吧，這是演算法課的口號)。只有想不斷提升的人，才會注意去扣各種各樣的細節， 使得自己做得比前一次好。

下面總結一下，常見的「地雷」主要有：

沒有提前構建

沒有規劃完整系統的生命周期，內存泄露到處都是。

系統沒有設計好，存在不少重複功能的類。

系統的行為沒有定義好，介面設計不完整，寫了創建不寫刪除。

沒有重視代碼的可讀性

代碼沒有經過提煉，到處都是重複代碼，改一個功能常常要改很多處代碼。

缺少抽象，將具體實現暴露得到處都是。比如一個狀態機在外部設置它的狀態切換。

代碼沒有緊貼語義。

沒有重視開發效率

到處都是繁雜重複的配置項，通過約定可以省去很多配置。

很多中間代碼，比如解析xml、解析協議等等的工作，通過元編程可以將這些中間工作自動化。

沒有重視數據

數據沒有處理好，敏感數據要保護好，比如角色的屬性，到處都是直接賦值的話，很容易出錯，要把直接改變限制在少數的某幾個函數里。

某些系統知道得太多，比如數據層就不應該知道顯示層的東西，顯示和數據摻雜在一起。

數據依賴於代碼，比如寫在C++的模板裡面，沒有為數據設計序列化文件。

最後，給習慣於埋雷的程序員兩點建議：

記住一句話：「我不是什麼偉大的程序員，我只是一個有著很多好習慣的程序員」—-Kent Beck

想明白一個問題：在《程序員修鍊之道》里，第一條就是「關心你的技藝」。如果你不在乎能否漂亮地開發出軟體，你又如何要耗費生命去開發軟體呢?

小編拉你進粉絲微信群

不是在文章評論里回

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！