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的情况。

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

　　当方法与构造方法拥有太多的参数时，我总是担心客户端无法正确地使用他们，特别是有些参数是相同类型的情况。如果一个方法接收了3个字符串和3个布尔值，那么客户端就很容易搞混传递进去的值。编译器在这种情况下也无能为力，检测问题的唯一办法就是在运行期(通过单元测试或是其他测试)查看调用结果。过多的参数表明了不恰当的设计。

　　过多的显式类型转换

　　显式类型转换最有可能是个危险信号，因为类型转换本身并不会影响到任何功能或是逻辑，不过这却表明情况与预想的不一致。类型转换表明了不太好的设计决策(比如说没有正确利用好多态、在不合适的地方使用了继承、或是强制将一些本不该放在一些的东西放到了一起)。当然了，显式类型转换在很多情况下是恰当和必要的(比如说在获取Spring框架的Bean时)，不过有时也表明设计上出现了问题。类型转换还表明API定义的范围过大或是API中使用的接口范围过大。

（编辑：辽源站长网）

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