八个改善 Java 遗留系统的技巧

你没看错，就是这个题目：即使是 Java 系统也会变成“遗留”系统。每当我们想起遗留系统时，我们就会想起那些存储着大量文件数据并只能用 COBOL 访问的嘎吱嘎吱作响的大型主机。但事实是，Java 已经是一门具有 15 年历史的开发语言，用 Java 写就的成千上万的系统已经成功运行了十年甚至更久。

因此，考虑到许多读者都会工作在某个遗留的 Java 系统上，我根据自己的经验特地攒了这八个技巧，来帮助团队更新和激活他们的遗留 Java 应用。

技巧 1：使用分析器

分析器提供了任何其他工具无法提供的功能，从而能够深入检查你的应用。如果你的应用已经有一年多时间没有被分析过了，那么它肯定会有大块大块的低效代码，潜伏在某个黑暗的角落。市面上有许多不同的或免费或商业的分析器。对于CPU 分析，我最喜欢的是 JProfiler ，因为它足够强大能分析出大多数问题，同时易于设置，尤其当你使用它内建的设置向导的时候。而诊断内存问题时，我最亲睐的工具是 Eclipse Memory Analyzer ，因为它使用的是记录在磁盘上的索引，而不是把整个堆的快照放到内存中。

通常来说，隐藏着的易耗尽 CPU 的代码包括低效的 hashCode() 或者 equals() 方法（在卷动 JTable 时以及使用 Java collection 类时，它们会被调用上百万次），以及一些出人意料的出自 Sun 之手的低效类，比如 SimpleDateFormat 。

分析器可能会明显地让你的应用变得很慢，所以你一定要在测试环境中使用它。

技巧 2：监控数据库使用状况

分析器除了可以显示你的应用过度占用 CPU 时钟的细节，它们也可以对你的应用在哪些地方长时间做了数据库的操作给出提示。但更好的用来监控数据使用的工具，是像 Proactive DBA 或者 HP Diagnostics ，或者任何其他来自于你的数据库产品厂商的工具。这些工具可以告诉你，哪些代码做了长时间的 SQL 调用，以及哪些代码在短时间内对同一行做了多次调用。来自数据库厂商的工具还可以帮助发现那些阻塞了其他调用的查询；虽然在我的经验里，这样的阻塞问题基本不过是些简单的、低效的 SQL 用法。

我写了一个新的工具叫做 jdbcGrabber ，它可以让你以可视化的形式描述出哪些代码正在访问哪些数据表。通过这种可视化呈现，你可以很容易发现那些多次访问数据库中不同部分信息的代码，从而将其调整为一次合并的请求。

技巧 3：构建和部署自动化

许多遗留系统缺乏一种完全自动化的方式，来构建它们的代码，更不用说自动部署了。自动化构建和部署对于提高遗留系统开发者的效率来说，是一种简单直接而又低风险的方式，而且通常不需要修改代码。

没有自动化的构建和部署过程，新的开发者不得不重新发明轮子，跟那些前辈们早就斗争过的同样问题重新来斗，而且每次重复的部署问题发生，开发者都会发明出不同的解决方案。

虽然 Maven 是一款卓越的而且使用广泛的构建工具，但它对你的源码树结构以及库依赖有着固执的要求，所以把它用在遗留应用中会有点困难。但足够优秀的 Ant 应该更易于使用，因为它处理起遗留代码结构更加灵活，也更容易部分采用，而不是全盘采用。

技巧 4：自动化你的操作并使用 JMX

另外一种提高遗留应用的效率但不会带来修改代码的风险的方式是，改善它的运维。许多内部开发的企业系统，一般都需要大量出人意料的手把手指导和维护，即使这样是不应该的。

既有的 Java 功能可以通过使用 JMX 很容易地暴露给负责运营的人们，而不会带来负面影响。许多开发者对 JMX 比较熟悉是因为，他们用 JMX 来跟 JBoss 和 WebLogic 这样的应用服务器进行交互，但他们不清楚把 JMX 用在他们自己的应用中是多么方便。任何 Java class 都可以通过 JMX 暴露出来，几乎没什么负面效果，也没有什么风险。

比如，如果你的应用有一个本地的静态 HashMap 作为 cache，你就可以通过 JMX 来暴露功能，从而很容易地清除那个 cache。

一旦应用通过 JMX 暴露，运维团队或者开发者就可以以良好的方式来操作应用，无需直接访问运行着应用的机器。

技巧 5：创建单元测试

一旦你对遗留系统的修改破坏了某个功能，你所面临的最大障碍之一就来到了。一些工具宣称能对代码进行反向工程，并为其创建单元测试，但我对这些工具没有太多的信心。要想有足够的信心，你的单元测试的确覆盖了你期望它们覆盖的代码，你就不得不亲自创建它们。

很幸运，为遗留代码创建单元测试并没有一开始感觉上的那样困难。我使用了 Michale Feathers 在 Working Effectively with Legacy Code 一书中讲解的“遗留代码修改算法”：

1. 确认修改点
2. 找出测试点
3. 打破依赖
4. 编写测试
5. 修改并重构

有效使用这个算法的窍门在于第 3 点：打破依赖。有很多技术可以用来干这个，但其中大多数都是关于移除静态引用以及在接口和 facade 下隐藏外部引用和复杂代码。一旦你具有这样打破依赖的感觉了，接触遗留代码就不会是一件让你提心吊胆的事情了。

技巧 6：杀死无用代码

虽然无用代码可能看起来无害，但它们实际上往往会是无声的杀手。原因在于只要无用代码还在代码库中，负责维护的程序员就不会非常确信，代码是真的无用还是只是看起来无用。感受过前几次修改所带来的痛苦的维护者都知道，即使是静态代码分析也不能证明代码是真的无用了。比如，十年前一些聪明的程序员可能会通过数据库中的字符串值来驱动 Java reflection 调用业务逻辑（别笑，我不止一次看到过这样）。

因此，杀死无用代码应用是第一优先级的任务。虽然 Emma 通常被认为是一种单元测试覆盖工具，但它可以用来侦测无用代码。当你把 Emma 注入到 JVM 中，它就可以追踪到哪些代码执行了，哪些没有。在你的开发环境中，把 Emma 和一个完整的测试周期相结合使用，你就会知道哪些代码活着还是死了。

技巧 7：采用一种“顺从”方式构建代码

遗留应用不可能一次清理完毕。在现实中，开发团队必须利用任何一次机会，来改善遗留代码。但许多团队对目前代码的情况都倍感失望，而无法考虑他们究竟该怎么做。“代码实在太糟糕了，”开发者说。

冷漠是最大的错误。遗留应用之所以还存活着是因为，它们依然有用，而且和所有有用的应用一样，他们的用户会继续想要修改它们。如果团队抓住机会定义一个可以达到的愿景：希望应用会是什么样子，然后做出逐步增量的改变，他们就会离距离最终的愿景更进一步。

没有这样的愿景，团队的每个成员就会做出任何他 / 她所认为最正确的事情。一个人会使用 Spring JdbcTemplate 而另一个人会开始使用 iBATIS/MyBatis。虽然每个人都真正期望改善这个应用，但事实上他们会让事情变得更糟，因为他们是在不同的方向上使力，使已经复杂的结构更加混乱。

技巧 8：升级你的 JRE

当我告诉一些团队 Sun（现在是 Oracle）早在 2009 年 11 月就已经宣称不在继续对 JDK 1.5 的支持时，他们仍然觉得惊讶不已。这不仅仅是立刻要升级 JRE 到 1.6 的事情。那些历经磨难的团队，还记得从 1.1 升级到 1.2 或者 1.4 升级到 1.5 时所发生的一切，他们可能对这样的升级还感到犹豫。但我的经验是，这样的升级会很平滑，而且会给应用带来一次显著的免费的性能飞跃。另外，JDK 1.6 还带来许多有用的、免费的运维和分析工具，来帮助诊断那些你这些年一直备受困扰的垃圾回收问题。

八个技巧之外

上面精心挑选出来的每个技巧，基本都是易于采用，并风险相对要低。但还有很多其他的方式来改善遗留应用，让应用改善后看起来就像是新的一样。

首先，现在的开放源代码库生态系统给过去大部分的遗留 Java 系统带来了生机。许多遗留系统会有土生土长、完全自定义的各种子系统：工作流引擎、规则引擎、模板引擎、用户接口框架以及对象关系映射层等等。这些土生土长的组件中的任意一个，都可以被一个免费的开放源代码库替换掉，而且更加智能并足够强壮。这样一对一的替换可以很大程度上消除一次全部替换所带来的维护上的困难。

其次，是时候好好看看你自己的遗留应用的设计问题了。虽然改变设计远比仅仅升级 JRE 要复杂得多，但它也会给你的投资带来更大的回报。对于大量逻辑都存储在数据库存储过程中的应用，可以考虑把那些逻辑提高到应用层，从而可以受益于集群服务器，并更容易进行单元测试。如果一个设计把表示层跟业务逻辑层绑定得太紧，那你就可以把它们分开，这样增加新潮的 iPhone 界面也会很容易实现。在各个子系统之间的同步调用也可以转换成异步、基于消息的调用，这在弹性和性能上都会是重要的改善。

最后，为了让你从 Java 遗留应用中多活两到四年，我建议你雇佣一个对这样系统有经验的专家。就像一个外科医生做精妙的大脑手术一样，有经验的专家通常可以为遗留系统中的问题找到更好的解决方案，从而带来更多的好处以及低风险。

对于那些期望吸取更深内容的读者，我建议这本我读过的最好的关于遗留系统的书：Michale Feather 的 _ Working Effectively with Legacy Code _。任何工作在遗留系统上的开发者都会从这本书中受益。

关于作者

Tim Cull 是一个有经验的软件开发人员和架构师。作为 Thedwick LLC（一家专注于高层次软件开发的精品软件咨询公司）的创始人，他已经帮助过很多客户扩展并增强他们的遗留 Java 系统，并保护他们的技术投资。Tim 最新的发表包括他的 blog（ http://www.thedwick.com/blog ）以及一篇在 IEEE 软件（需要订阅）上的文章。更多信息，请联系 feedback@thedwick.com 或访问 http://www.thedwick.com 。

查看英文原文： Eight Quick Ways to Improve Java Legacy Systems

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。