以前聽說過軟件系統中有定時炸彈，今天我領教了代碼中的地雷。

所謂地雷，它的特性是安裝容易拆除難，下面段代碼完全符合地雷的特性。

public static void GetAvail(SegmentType segment, out int avail) {if(segment.StartDate < DateTime.Now)segment.ClientTypes.ForEach(n=>n.MaxAvail = 0);//.... }

這是一個底層方法，依賴于它的代碼較多，即它的扇出較大。

這個函數的本意是獲取avail，但在獲取avail的同時染指了segment實例，而這個行為并未通過函數的名稱表現出來。這就意味著，只想通過該函數來獲取avail的程序員得到了一個意外的結果，傳入的segment實例被意外地修改了，而這個修改肯定不會在它的設計之中，所以接下來就可能會出現莫名其妙的邏輯錯誤--他踩上這顆地雷。

現在，我們發現了這個“地雷”要將其排除掉，是否可以直接將其刪除呢？我只能說你可以試試，如果你膽子夠大且不怕系統出現其他問題。

現在，我們不能保證不存在這樣的上下文，即依賴于GetAvail中的那段所謂的“地雷”代碼才能夠正確執行。如果這樣的上下文存在，那么貿然地刪除這段代碼的同時也將引爆這顆“地雷”。

而要排除這顆“地雷”，其驚險程度不亞于排除一顆真正的地雷，因為你不知道到底有多少上下文直接或間接地依賴于這個函數。你必須將這些依賴一個一個地列出來，然后逐一分析，然后做出正確的決定。這其中的險在于沒有一個參照物可以幫你證明你已經將所有的依賴都分析完了。所以當產品發布時，你還得提心吊膽。

如何解決，地雷問題。我認為有兩點可以有所幫助。

模塊化，盡量將功能的范圍限制在模塊內，因此也限制了可能的錯誤的波及范圍

將扇出較大的功能放在系統底層構架的范圍內，而對系統底層構架的任何變動都要做嚴密的監視。

也希望聽聽大家對代碼中的地雷的看法。

轉載于:https://www.cnblogs.com/czy/archive/2010/06/19/1761055.html

總結

以上是生活随笔為你收集整理的代码中的地雷的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。