因此，既要深入了解Java语言，又要深入了解你在应用中使用的框架，这样才能分析出一个改变的影响。

　　当你提高了如上两个技能，尽管你对项目不是非常了解，但大部分的维护任务会变得简单很多。如果你想要修复一个bug，会定位并修复这个bug，并且保证变更不会破坏项目的其他部分。如果你想要增强或加入特性，基本上你只需要模仿现有的特性，使用类似的设计。

　　在一个在线银行项目中，为什么“查看账户摘要”和“查看交易历史”的设计要有巨大的差别呢？如果你理解了“查看账户摘要”的设计，完全可以模仿开发出“查看交易历史”的功能。

　　修复bug和增强来说，你不必完全理解所有2000个类的工作内容和代码驱动系统运行的原理。只要有上面的技能，你能很快定位需要修改的代码，使用良好的java和框架技能修复，保证变更不会破坏项目的其他部分，然后交付，尽管你可能只知道一小部分项目的设计。

　　4、使用工具找到所需变更内容以及变更产生的影响

　　继续我们尽快交付的主题，你应该寻找工具作为辅助，只需要对项目又很少理解，能帮助你尽快实施交付。

　　4.1 迅速发现所需变更内容的工具

　　无论是修复bug还是增强系统，首先你都要找到该用例调用且需要修改的类及方法。基本上有两种方式理解用例的工作方式，静态代码分析和运行时分析。

　　源码分析统计会扫描所有代码并且展现类之间的关系。市场上有很多工具。比如：Architexa、AgileJ、UModel、Poseidon等。

　　所有静态代码分析工具的缺点在于，它们无法确切展现 用例中类或方法的运行时调用情况。因此Java新加入了一些特性，如回调机制（callback patterns）。比方说，静态分析工具无法推断出当前页面提交按钮被点击时，会调用哪个Servlet。

　　运行时分析工具能够展现类和方法在用例运行时的状态。这样的工具包括：MaintainJ、Diver、jSonde、Java Call Tracer等。这些工具可以捕获运行时的堆栈状态，并以此为用例生成序列图和类图。

　　序列图会展现该用例在运行时所有调用的方法。如果你在修复bug，那么这个bug很可能是这些被调用的方法之一。

　　如果你在增强已有功能，可能是新增验证，修改DAO等，那么可以利用序列图理解调用流程然后再修改。

　　如果你在新增功能，那么可以找到一些相似的特性，利用序列图理解调用流程，然后模仿开发新功能。

　　要仔细地挑选运行时分析工具。信息过多是这类工具的主要问题。选择一些工具，能够提供简单的信息，过滤掉无效信息，并能够方便的查看各种视图。

　　4.2 迅速发现所需变更内容的工具

　　若单元测试有效，你可以通过运行单元测试发现变更有没有破坏其他测试用例。有效维护并且覆盖大型企业应用的单元测试还是比较少的。下面有一些针对该情况的工具。

　　在此，仍然是有两种技术——静态代码分析和运行时分析——可以使用。市场中有很多静态代码分析工具可用。如：Lattix、Structure101、Coverity、nWire和IntelliJ's DSM。

　　对于变更后的类，上述工具均可识别对该类存在依赖的类的集合。开发者需要根据这些信息“猜测”可能产生影响的用例，因为这些工具无法展示运行时类之间的调用关系。