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

清除java

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

吞咽检查异常

当我们不小心在代码中引入了错误时，异常是让我们放弃的事情之一。在方法上声明throws子句或catch选中的Exception也很麻烦。解决这两个问题的方法是，在可能引发该异常并且什么也不做的情况下，简单地捕获该异常（即使它是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或集合），但有时我们必须更具创造力，以避免使用null 。在此处可以使用“默认”非null值代替null 。关于如何处理此任意非null默认值，有两种思路。一种方法是使用数据集中最常见的值作为默认值，因为如果无论如何还是很常见，当出现更多的该值并且您更有可能拥有看起来像这样的代码时，可能不会注意到它。处理该共同价值而无任何意外。另一方面，如果您拥有一个几乎从未使用过的值，那么它可以成为一个很好的默认值，因为受它影响的代码（尤其是经过良好测试的代码）可能比通常期望的值少。