作為一名開發(fā)者，我想，你最不希望發(fā)生的事情之一是：當你調試一個Bug的時候，Bug就消失了，但直接運行的時候，Bug又出現(xiàn)了。

通過 #ifdef DEBUG 技法，可以將額外的調試代碼放置到程序中。畢竟，這些調試代碼僅會在程序的調試版本中才會生效。但是，一定要注意的是，這些調試代碼不應該修改程序的執(zhí)行邏輯。

你可以在調試代碼中執(zhí)行參數(shù)驗證，執(zhí)行斷言，追蹤資源的使用，這可能會降低程序的性能并消耗更多的計算資源，這些都是可以接受的，唯一需要注意的一條是：不要在調試代碼中修改程序的流程。

我們來看看下面的例子。

上面的代碼是錯誤的，你是否已經(jīng)看出來了？
調試版本的行為與發(fā)行版本根本不同。如果有人使用 NULL 為 p 參數(shù)調用此函數(shù)，則程序的發(fā)行版本將崩潰，但調試版本將捕獲錯誤并使調用失敗。

不要在調試版本中修改函數(shù)的語義。如果發(fā)行版本崩潰，則調試版本也必須以相同的方式崩潰。當然，你可以在崩潰之前記錄錯誤日志信息，但你仍然需要它”崩潰”，和發(fā)行版本行為保持一致。

下面是一個展現(xiàn)了類似問題的 C# 代碼的例子。

在上面的例子中，調試版本記錄并吞掉了異常，而發(fā)行版本直接讓異常跳出了此函數(shù)。

如果你恰好也寫了這樣的代碼，發(fā)行版本和調試版本的行為方式根本不同，你最終會陷入這種情況：發(fā)行版本有一些問題，但調試版本工作正常。

你的客戶無法弄清楚有什么區(qū)別，因此他們切換到生產服務器上的調試版本。它的運行速度是原來的兩倍，內存消耗的內存是原來的三倍，需要大量的資源才能擴展到以前的服務級別。但這是他們能做的最好的事情，因為問題不會出現(xiàn)在調試版本上（因此無法在那里調試）。

我看到過關于軟件陷入這種困境的報道，這對開發(fā)人員的影響非常糟糕。

總結

今天的論點也是我一直所忽視的：調試的代碼，就干調試的活，不要做其他事情，更不要修改程序執(zhí)行流程。
第二個：調試版本和發(fā)行版本可能在執(zhí)行速度，占用資源存在差異，但兩者的行為必須完全一致。