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

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

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

我們來(lái)看看下面的例子。

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

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

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

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

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

你的客戶(hù)無(wú)法弄清楚有什么區(qū)別，因此他們切換到生產(chǎn)服務(wù)器上的調(diào)試版本。它的運(yùn)行速度是原來(lái)的兩倍，內(nèi)存消耗的內(nèi)存是原來(lái)的三倍，需要大量的資源才能擴(kuò)展到以前的服務(wù)級(jí)別。但這是他們能做的最好的事情，因?yàn)閱?wèn)題不會(huì)出現(xiàn)在調(diào)試版本上（因此無(wú)法在那里調(diào)試）。

我看到過(guò)關(guān)于軟件陷入這種困境的報(bào)道，這對(duì)開(kāi)發(fā)人員的影響非常糟糕。

總結(jié)

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