這樣寫程式，更容易 debug

原文：Write code that’s easy to delete, and easy to debug too.

「寫出容易 debug 程式碼的第一步：理解到自己沒過多久就會忘記關於這段程式碼的一切。」

軟體工程師 Thomas Figg 在這篇文章中 討論他建議開發者可以怎麼樣寫出好維護、容易找出程式錯誤並修正的程式碼。

他的建議大致分為兩個項目： 「寫作程式的心態」以及「管理程式的制度」。

譬如他認為設計程式的第一步 開發者必須要先釐清程式在運行時，會遇到哪些狀態（state）以及相對應的處理方式； 他另外提到像是事先計畫、工具與技術文件 也都能幫助釐清錯誤的責任歸屬與源頭，進而提升程式修正的速度。

–

寫出容易刪除也容易偵錯的程式碼

可偵錯的程式碼依舊是程式碼，不會比你更聰明． 有些程式碼比起其他的程式碼，就是有那麼一點更難去偵錯… - 有著一些隱藏式行為的程式碼 (hidden behaviour) - 糟糕的錯誤處理 (poor error handling) - 模棱兩可 (ambiguity) - 過少或是過多的結構 (structure) - 夾雜在正在被改變的程式碼中間 (code that’s in the middle of being changed)

在一個夠大的專案裡面，你最終就會一頭栽進那些你完全不了解的程式碼之中．

在一個歷史悠久的專案中，你將會探索那些程式碼卻忘記了如何撰寫- 且如果你沒有去查看它的交付紀錄，你必定會發誓那是其他人寫的 當一個專案越具規模了之後，每一個片段的程式碼功用便會變得難以被記住 更困難的是，這些程式碼沒有做到那些它原本應該做到的事… 當你必須去改變那些你完全不了解的程式碼時 你就必須強迫學習這條艱辛的道路：偵錯 (Debugging)

如何寫出那些容易偵錯的程式碼？那就是先明白一件事 - 在你寫完這段程式碼之後，你不會記得這段程式碼的任何內容…

規則零：再好的程式碼也都會有明顯的缺點

規則一：電腦總是會故障

規則二：你的程式總是與自己交戰

規則三：你不把那些模棱兩可的地方消除，你晚點就必須下中斷點去偵錯

規則四：偶發的行為就是預期會發生的行為

規則五：在你認為進行偵錯是技術性行為之前，它其實是社交性行為

那些越容易被偵錯的程式碼也會更容易被解釋說明