因?yàn)檐浖e(cuò)誤可能使我們在開發(fā)人員面前看起來很糟糕，并導(dǎo)致其他人對我們的想法減少，所以最好避免編寫錯(cuò)誤，快速識別和修復(fù)錯(cuò)誤或掩蓋我們的錯(cuò)誤。 有許多博客文章和文章討論如何避免錯(cuò)誤以及如何識別和修復(fù)錯(cuò)誤，因此，在這篇博客文章中，我將介紹一些在地毯下掃除Java代碼庫中問題的最有效策略。

吞咽檢查異常

當(dāng)我們不小心將錯(cuò)誤引入代碼時(shí)，異常是讓我們放棄的事情之一。 在方法上聲明throws子句或catch選中的Exception也很麻煩。 解決這兩個(gè)問題的方法是，在可能引發(fā)該異常RuntimeException執(zhí)行任何操作的情況下，簡單地捕獲該異常（即使它是RuntimeException ）。 這樣可以使API保持簡潔，并且?guī)缀鯖]有人可以對已檢查的異常進(jìn)行處理。 通過不對其進(jìn)行記錄或執(zhí)行任何操作，甚至沒有人需要知道它曾經(jīng)發(fā)生過。

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

失敗的單元測試會分散您的注意力，使您難以確定新功能何時(shí)破壞了測試。 當(dāng)我們通過代碼更改破壞了某些內(nèi)容時(shí)，它們也可以顯示。 注釋掉這些失敗的單元測試將使單元測試報(bào)告更整潔，并使查看他人的新功能是否破壞單元測試變得更加容易。

在基于JUnit的單元測試中使用

注釋掉失敗的單元測試似乎很令人厭惡，因此另一種可能更令人愉悅的選擇是使用@Ignore批注來注釋基于JUnit的失敗單元測試方法。

完全刪除個(gè)別測試

如果用@Ignore注釋掉一個(gè)損壞的測試或用@Ignore注釋一個(gè)損壞的測試是不令人滿意的，因?yàn)橛腥巳匀豢梢詸z測到我們已經(jīng)破壞了一個(gè)單元測試，我們可以簡單地完全刪除有問題的單元測試。

注釋違規(guī)斷言

我們不必注釋掉或刪除整個(gè)測試。 它就像在單元測試方法中注釋掉或刪除assert語句一樣簡單。 該方法每次都可以成功執(zhí)行并運(yùn)行，因?yàn)闆]有斷言意味著沒有辦法失敗。 當(dāng)單元測試方法非常長且令人費(fèi)解，從而不容易發(fā)現(xiàn)缺少斷言時(shí)，這特別有效。

分散無用和冗余測試的噪音

注釋單元測試，使用@Ignore注釋基于JUnit的單元測試，甚至刪除單元測試對于在Java底下掃除問題的策略可能也太明顯了。 為了使這些變得不那么明顯，另一種有效的策略是在同一單元測試類中編寫許多不必要的和多余的測試方法，以便看起來正在進(jìn)行全面的測試，但實(shí)際上只有一小部分功能（我們知道的子集是工作）正在測試中。

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

我們可以利用以下事實(shí)：單元測試只能測試單元測試的作者認(rèn)為被測軟件的預(yù)期行為，從而編寫能夠證明我們的代碼正確的單元測試。 如果提供2和2時(shí)，我們將兩個(gè)整數(shù)相加的代碼意外返回5的和，我們可以簡單地將單元測試中的預(yù)期結(jié)果也設(shè)置為5。會顯示漂亮的單元測試報(bào)告，而不必是明智的。

避免記錄詳細(xì)信息

日志可能會暴露一個(gè)人的軟件問題，而應(yīng)對這種風(fēng)險(xiǎn)的有效方法是完全不進(jìn)行日志記錄，僅記錄常規(guī)操作和結(jié)果，并在記錄的消息中保留詳細(xì)信息（尤其是上下文）。 過多記錄平凡的細(xì)節(jié)也可能使任何更有意義的消息模糊，這些消息可能會揭示我們代碼的弱點(diǎn)。

避免使用描述性的

一個(gè)描述性的toString()方法可能會過多地揭示任何給定實(shí)例的狀態(tài)，并揭示我們的錯(cuò)誤。 不覆蓋Object.toString()可能會使識別問題和將問題與任何給定的代碼或開發(fā)人員相關(guān)聯(lián)變得更加困難。 跟蹤問題所需的額外時(shí)間使您有更多時(shí)間進(jìn)入下一個(gè)項(xiàng)目，然后才發(fā)現(xiàn)是您的代碼有問題。 如果編寫的Java類使用描述性的toString()擴(kuò)展了類，則可以在擴(kuò)展類中覆蓋該方法以不執(zhí)行任何操作（有效地刪除可能導(dǎo)致問題的toString()輸出）。 如果希望它看起來像從未在繼承層次結(jié)構(gòu)中實(shí)現(xiàn)過，請確保擴(kuò)展類的toString()方法返回System.identityHashCode（this） 。

不要讓

NullPointerException可能是Java開發(fā)人員處理的最常見的異常。 這些特別危險(xiǎn)，因?yàn)樗鼈兺ǔ沂敬a的弱點(diǎn)。 try僅包裝每一行代碼的一種策略– catch并簡單吞下異常（包括NPE）。 另一個(gè)不太明顯的策略是通過從不返回或傳遞null來避免NPE。 有時(shí)，可以使用明顯的默認(rèn)值代替null （例如，空的String或collection），但有時(shí)我們必須更有創(chuàng)造力，以避免null 。 在此處可以使用“默認(rèn)”非null值代替null 。 關(guān)于如何處理此任意非null默認(rèn)值，有兩種思路。 一種方法是使用數(shù)據(jù)集中最常見的值作為默認(rèn)值，因?yàn)槿绻匀缓艹Ｒ?#xff0c;那么當(dāng)該值中出現(xiàn)更多的值并且您更有可能擁有看起來像這樣的代碼時(shí)，可能不會注意到該值。處理該共同價(jià)值而無任何意外。 另一方面，如果您擁有一個(gè)幾乎從未使用過的值，那么它可以成為一個(gè)很好的默認(rèn)值，因?yàn)槭芩绊懙拇a（尤其是經(jīng)過良好測試的代碼）可能比通常期望的值少。

結(jié)論

當(dāng)我回顧這些策略以掃除底層Java代碼問題時(shí)，我注意到了一些重復(fù)出現(xiàn)的主題。 就暴露我們軟件的弱點(diǎn)而言，異常，日志記錄和單元測試特別麻煩，因此，有效地“發(fā)現(xiàn)我們的足跡”的大多數(shù)方式都與異常，日志記錄和單元測試的處理有關(guān)就不足為奇了。

翻譯自: https://www.javacodegeeks.com/2017/04/effectively-sweep-problems-rug-java.html

總結(jié)

以上是生活随笔為你收集整理的如何在Java地毯下有效地清除问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。