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