Java开发者必知：开发中常见的危险信号

　　关闭编译器警告与IDE和工具的警告及提示信息

　　当然了，我并不认为FindBugs所标识出的Java代码中的每个问题都是Bug或是Defect。事实上，在某些情况下，我甚至会禁用掉某些提示信息，因为我并不认为这些提示信息是正确的，他们会搞乱FindBugs的输出。也就是说，如果关闭提示信息你需要非常谨慎才行，确保只忽略掉那些不正确的提示信息而保留下重要的警告信息。类似地，我倾向于开启很多IDE警告，不过会将其中一小部分关闭掉。我觉得在禁用掉javac警告的情况下来构建Java应用并不是明智之举。这样做会隐藏掉出现的危险信号，不过关闭这些警告信息的动作本身很可能就是个更大的危险信号，因为这些警告与提示信息会指出很多潜在的危险信号，需要你重点关注。

　　过度工程化与过早优化

　　过于复杂的软件通常是一种常见的开发者失调行为的结果。为了代码的灵巧而丧失可读性，或是关注于灵活性及进行没必要的过早优化而造成可读性的降低常常会导致其他问题的产生。过度工程化的开发者常常会这么做，看看能否用点什么新玩儿意，不过这对于高质量的软件来说却并没有什么好处。一旦软件变得过于复杂并且难以理解，那么维护起来就不是那么容易的事情了，而且常常会导致修改时出现问题。

　　举个例子，在阅读代码时你可能想知道为什么开发者没有采取更加直接的方式来实现。一方面，你可能感叹于开发者能够使用一些更加高级的特性，但另一方面，你可能又会觉得这么做要比正常情况更加复杂了。有很多事实可以证明这是一个危险信号，不过我只在几个地方看到有人会这么做。一种情况是将本来用静态Java代码实现好好的众多功能改用反射、Spring或是其他依赖注入、动态代理、观察者模式等方式来实现。如果用得好的话当然没什么问题，不过我经常看到有人过度使用或是滥用这些特性，这直接导致其他开发者很难理解代码的意图与作用。

　　将日志消息直接输出到控制台

　　Java中的日志框架由来已久，如今已经有为数不少的日志框架(有些框架构建在别的框架之上)，这包括传统的Log4j 1.2、Log4j 2、java.util.logging(Java Logging API)、Apache Commons Logging及SLF4J等。既然有这么多的日志框架，因此我会很奇怪为什么很多Java代码中还有System.out与System.err语句。

　　Java代码中存在着向标准输出与标准错误中进行输出可能有很多原因。其中一个原因就是有些代码还不太成熟，后面还会修改，改成输出到日志，不过到最后也没有改。使用标准输出与标准错误的另一个弊端就是这些日志消息并不会被写到日志文件中，而使用日志框架的日志消息则会被写到文件中，这样就会出现不一致的情况。第3个问题就是日志框架提供了不少优秀的特性，如果直接写到标准输出或是标准错误中就无法使用这些特性了。这些特性包括轻松控制日志消息的级别、轻松将捕获到的异常关联到一个日志错误消息上、轻松将输出重定向到不同的目标及使用不同的格式等。虽然在直接使用输出与错误流时这些都可以通过手工来实现，不过这需要自己编写代码而不是“开箱即用的”。

　　除了直接使用System.out与System.err外，有些Java代码还是会将信息写到标准输出与标准错误上(通常也是隐含使用了System.out与System.err)。比如说，Throwable.printStackTrace()(在处理异常时常常会用到)就会这么做，根据Javadoc的说明，它会将异常与堆栈信息打印到标准错误流中。

　　使用StringBuffer而非StringBuilder

　　坦白地说，这只是个小问题而已，不过却能标识出过时的Java代码(StringBuffer是JDK 1.0引入的，而StringBuilder则是J2SE 5引入的)或是开发者并没有真正理解他们之间的区别。在大多数情况下，这两者之间的性能差别对于应用来说是微乎其微的，但由于StringBuilder更适合于大多数使用了StringBuffer的场景，因此我们还是可以从StringBuilder获得性能上的微小提升。 我很少发现使用StringBuffer而不能使用StringBuilder的情况。

　　方法与构造方法中使用了过多的参数

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!