因為軟件缺陷會讓我們在開發人員中顯得很糟糕，并導致其他人對我們的看法降低，所以最好避免編寫缺陷，快速識別和修復缺陷，或者掩蓋我們的缺陷。有許多博客文章和文章討論如何避免bug以及如何識別和修復bug，因此，在這篇文章中，介紹一些最有效的策略，以徹底解決Java代碼庫中的問題。

[[439958]]

1. 吞咽檢查異常

當我們不小心在代碼中引入了bug時，異常就是其中之一。在方法上聲明throws子句或捕獲已檢查的異常也是一件麻煩事。這兩個問題的解決方案都是在異常可能被拋出時捕獲異常(即使它是正在運行時一場)，而不執行任何操作。這使API保持簡潔，對于檢查的異常，人們幾乎無能為力。通過不記錄它或對它做任何事情，甚至沒有人需要知道它曾經發生過。

2. 注釋掉或刪除不滿意的單元測試

失敗的單元測試可能會讓人分心，并且很難確定新功能何時破壞了測試。它們還可以揭示我們在代碼更改時破壞了某些東西。注釋掉這些失敗的單元測試將使單元測試報告更清晰，并且更容易查看是否有其他人的新功能破壞了單元測試。

3. 在基于JUnit的單元測試中使用@Ignore

注釋掉失敗的單元測試似乎令人不快，所以另一個可能更令人愉快的選擇是用@Ignore注釋失敗的基于JUnit的單元測試方法。

4. 完全刪除單個測試

如果用@Ignore注釋一個中斷的測試或用@Ignore注釋一個中斷的測試是不令人滿意的，因為有人可能仍然檢測到我們破壞了一個單元測試，那么我們可以簡單地將有問題的單元測試全部刪除。

5. 注釋掉令人不快的斷言

我們不一定需要注釋掉或刪除整個測試。它可以簡單到注釋掉或刪除單元測試方法中的斷言語句。該方法每次都可以成功執行和運行，因為沒有斷言意味著沒有失敗的方法。當單元測試方法非常長且復雜，因此不容易發現缺少斷言時，這種方法尤其有效。

6. 用無用和冗余測試的噪音分散注意力

注釋掉單元測試，用@Ignore注釋基于JUnit的單元測試，甚至刪除單元測試，對于在Java中徹底解決問題來說，這些策略可能太明顯了。為了使這些不那么明顯，另一個有效的策略是在同一個單元測試類中編寫大量不必要的和冗余的測試方法，這樣看起來似乎正在進行全面的測試，但實際上，只有一小部分功能(我們知道的子集正在工作)正在進行測試。

7. 編寫單元測試，以“證明”您的代碼是正確的，即使它不是

我們可以利用這樣一個事實，即單元測試只能測試單元測試的作者認為被測試軟件的預期行為，從而編寫單元測試來證明我們的代碼是正確的。如果我們將兩個整數相加的代碼在提供2和2時意外返回5的總和，那么我們可以簡單地將單元測試中的預期結果也設置為5。給出了一份漂亮的單元測試報告，沒有人會更明智。

8. 避免記錄詳細信息

日志可能會暴露軟件問題，處理此風險的有效方法是根本不記錄日志，只記錄例行操作和結果，并在記錄的消息中留下詳細信息(尤其是上下文)。對平凡細節的過度記錄也會掩蓋任何可能暴露代碼弱點的更有意義的消息。

9. 避免使用描述性的toString()實現

一個描述性的toString()方法可以揭示太多關于任何給定實例的狀態，并揭示我們的錯誤。不覆蓋對象。toString()會使識別問題和將問題與任何給定代碼或開發人員關聯變得更加困難。跟蹤問題所需的額外時間為您提供了更多的時間，以便在發現是您的代碼出了問題之前進入下一個項目。如果您編寫的Java類使用描述性toString()擴展了一個類，那么您可以在擴展類中重寫該方法而不做任何事情(有效地刪除可能導致toString()錯誤的輸出)。如果您想讓它看起來好像從未在繼承層次結構中實現過一樣，請確保擴展類的toString()方法返回系統。標識hash代碼(此)。

10. 不要讓NullPointerExceptions背叛你

NullPointerExceptions可能是Java開發人員處理的最常見的異常。這些特別危險，因為它們經常暴露代碼的弱點。一種策略是簡單地用try-catch包裝每一行代碼，并簡單地吞下異常(包括NPE)。

另一個不太明顯的策略是通過從不返回或傳遞空值來避免NPE。有時，使用默認值代替null(例如空字符串或集合)是有意義的，但有時我們必須更具創造性地避免null。在這一點上，使用“默認”非空值代替空值是很有用的。

關于如何處理這種任意的非空缺省值，有兩種觀點。一種方法是使用數據集中最常見的值作為默認值，因為如果它是通用的，那么當更多的值出現時，可能不會注意到它，并且您更有可能擁有處理該通用值的代碼，而不會發生意外。另一方面，如果您有一個幾乎從未使用過的值，這可以成為一個良好的默認值，因為受它影響的代碼(尤其是經過良好測試的代碼)可能比通常預期的值少。