如何在Java地毯下有效地清除问题

因为软件错误可能使我们在开发人员面前看起来很糟糕，并导致其他人对我们的想法减少，所以最好避免编写错误，快速识别和修复错误或掩盖我们的错误。有许多博客文章和文章讨论如何避免错误以及如何识别和修复错误，因此，在这篇博客文章中，我将介绍一些在地毯下扫除Java代码库中问题的最有效策略。

吞咽检查异常

当我们不小心将错误引入代码时，异常是让我们放弃的事情之一。在方法上声明throws子句或catch选中的Exception也很麻烦。解决这两个问题的方法是，在可能引发该异常RuntimeException执行任何操作的情况下，简单地捕获该异常（即使它是RuntimeException ）。这样可以使API保持简洁，并且几乎没有人可以对已检查的异常进行处理。通过不对其进行记录或执行任何操作，甚至没有人需要知道它曾经发生过。

注释掉或删除不满意的单元测试

失败的单元测试会分散您的注意力，使您难以确定新功能何时破坏了测试。当我们通过代码更改破坏了某些内容时，它们也可以显示。注释掉这些失败的单元测试将使单元测试报告更整洁，并使查看他人的新功能是否破坏单元测试变得更加容易。

在基于JUnit的单元测试中使用

注释掉失败的单元测试似乎很令人厌恶，因此另一种可能更令人愉悦的选择是使用@Ignore批注来注释基于JUnit的失败单元测试方法。

完全删除个别测试

如果用@Ignore注释掉一个损坏的测试或用@Ignore注释一个损坏的测试是不令人满意的，因为有人仍然可以检测到我们已经破坏了一个单元测试，我们可以简单地完全删除有问题的单元测试。

注释违规断言

我们不必注释掉或删除整个测试。它就像在单元测试方法中注释掉或删除assert语句一样简单。该方法每次都可以成功执行并运行，因为没有断言意味着没有办法失败。当单元测试方法非常长且令人费解，从而不容易发现缺少断言时，这特别有效。

分散无用和冗余测试的噪音

注释单元测试，使用@Ignore注释基于JUnit的单元测试，甚至删除单元测试对于在Java底下扫除问题的策略可能也太明显了。为了使这些变得不那么明显，另一种有效的策略是在同一单元测试类中编写许多不必要的和多余的测试方法，以便看起来正在进行全面的测试，但实际上只有一小部分功能（我们知道的子集是工作）正在测试中。

编写单元测试，即使不正确，也可以“证明”您的代码是正确的

我们可以利用以下事实：单元测试只能测试单元测试的作者认为被测软件的预期行为，从而编写能够证明我们的代码正确的单元测试。如果提供2和2时，我们将两个整数相加的代码意外返回5的和，我们可以简单地将单元测试中的预期结果也设置为5。会显示漂亮的单元测试报告，而不必是明智的。

避免记录详细信息

日志可能会暴露一个人的软件问题，而应对这种风险的有效方法是完全不进行日志记录，仅记录常规操作和结果，并在记录的消息中保留详细信息（尤其是上下文）。过多记录平凡的细节也可能使任何更有意义的消息模糊，这些消息可能会揭示我们代码的弱点。

避免使用描述性的

一个描述性的toString()方法可能会过多地揭示任何给定实例的状态，并揭示我们的错误。不覆盖Object.toString()可能会使识别问题和将问题与任何给定的代码或开发人员相关联变得更加困难。跟踪问题所需的额外时间使您有更多时间进入下一个项目，然后才发现是您的代码有问题。如果编写的Java类使用描述性的toString()扩展了类，则可以在扩展类中覆盖该方法以不执行任何操作（有效地删除可能导致问题的toString()输出）。如果希望它看起来像从未在继承层次结构中实现过，请确保扩展类的toString()方法返回System.identityHashCode（this）。

不要让

NullPointerException可能是Java开发人员处理的最常见的异常。这些特别危险，因为它们通常会揭示代码的弱点。 try仅包装每一行代码的一种策略– catch并简单吞下异常（包括NPE）。另一个不太明显的策略是通过从不返回或传递null来避免NPE。有时，可以使用明显的默认值代替null （例如，空的String或collection），但有时我们必须更有创造力，以避免null 。在此处可以使用“默认”非null值代替null 。关于如何处理此任意非null默认值，有两种思路。一种方法是使用数据集中最常见的值作为默认值，因为如果仍然很常见，那么当该值中出现更多的值并且您更有可能拥有看起来像这样的代码时，可能不会注意到该值。处理该共同价值而无任何意外。另一方面，如果您拥有一个几乎从未使用过的值，那么它可以成为一个很好的默认值，因为受它影响的代码（尤其是经过良好测试的代码）可能比通常期望的值少。