网站站内优化方案,佛山外贸网站建设哪家好,做展馆好的设计网站,wordpress 主题 seo因为软件错误可能使我们在开发人员面前看起来很糟糕#xff0c;并导致其他人对我们的想法减少#xff0c;所以最好避免编写错误#xff0c;快速识别和修复错误或掩盖我们的错误。 有许多博客文章和文章讨论如何避免错误以及如何识别和修复错误#xff0c;因此#xff0c;在… 因为软件错误可能使我们在开发人员面前看起来很糟糕并导致其他人对我们的想法减少所以最好避免编写错误快速识别和修复错误或掩盖我们的错误。 有许多博客文章和文章讨论如何避免错误以及如何识别和修复错误因此在这篇博客文章中我将介绍一些在地毯下扫除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.identityHashCodethis 。 不要让 NullPointerException可能是Java开发人员处理的最常见的异常。 这些特别危险因为它们通常会揭示代码的弱点。 try仅包装每一行代码的一种策略– catch并简单吞下异常包括NPE。 另一个不太明显的策略是通过从不返回或传递null来避免NPE。 有时可以使用明显的默认值代替null 例如空的String或collection但有时我们必须更有创造力以避免null 。 在此处可以使用“默认”非null值代替null 。 关于如何处理此任意非null默认值有两种思路。 一种方法是使用数据集中最常见的值作为默认值因为如果仍然很常见那么当该值中出现更多的值并且您更有可能拥有看起来像这样的代码时可能不会注意到该值。处理该共同价值而无任何意外。 另一方面如果您拥有一个几乎从未使用过的值那么它可以成为一个很好的默认值因为受它影响的代码尤其是经过良好测试的代码可能比通常期望的值少。 结论 当我回顾这些策略以扫除底层Java代码问题时我注意到了一些重复出现的主题。 就暴露我们软件的弱点而言异常日志记录和单元测试特别麻烦因此有效地“发现我们的足迹”的大多数方式都与异常日志记录和单元测试的处理有关就不足为奇了。 翻译自: https://www.javacodegeeks.com/2017/04/effectively-sweep-problems-rug-java.html
