市场上可以用于运行时影响分析的工具并不多，可能只有MaintainJ。MaintainJ先会捕获在用例中调用的所有类和方法。当所有用例的上述信息都被捕获之后，很容易发现类的变更对用例的影响。MaintainJ能够有效工作的前提条件是项目的所有用例都应当先运行一遍，以便能够获得运行时的依赖关系。

　　总之，目前你在迅速准确分析变更影响方面，还是可以从工具中获得有限的帮助。首先根据需要实施一些影响分析，然后根据自己或小组其他高级成员评审来判断变更的影响。你可能需要使用上述工具对你的判断进行反复确认。

　　5、对上述内容的两个忠告

　　5.1 不要降低代码质量

　　为了快速交付，可以不全盘理解架构，但绝不能以降低代码质量为条件。下面是一些你可能因为只考虑快速交付而引发的代码质量问题。

　　因为修改代码涉及到很多的依赖关系，所以新增代码相对而言风险较小。例如，有五个用例都调用了某个方法。为了改进某个用例，你需要修改这个方法的实现。简单的做法是复制这个方法，重命名，然后在改进的用例中调用新方法。千万不要这么做。代码冗余是非常有害的。你要尝试对方法进行包装或者重写，甚至是直接修改，然后重新测试所有用例，通常停下来想一想，然后亲手去实施，是一种不错的方式。

　　另一个例子是将“private”方法改为“public”，让别的类也可以调用。尽量不要将非必须的部分暴露出来。假如是为了更好的设计而需要重构，那么应当着手去做。

　　大部分应用都有确定的结构和模式来实施。修复或增强程序时，你要确保不会偏离这样的模式。如果对规约不确定，那么请其他高级开发者来审核你的变更。如果你必须做一些违背规约的动作，那么尽量放置于规模较小的类中（一个200行代码的类中的私有函数应当不会影响应用的整体设计）

　　5.2 不要停止深入理解项目架构

　　按照文章列出的方式，假设你能够在对项目了解较少的情况下进行交付，并持续这样下去，可能会停止对项目架构的深入了解。这从长远角度来说对你的职业生涯没有帮助。当你的经验增加时，会承担比较大的模块任务。如构建一个完整的新特性，或者修改项目的一些基础设计等较大的改进。当能够做这些改进时，你对项目的整体架构应该相当了解。文中列举的方法只是让你在短的时间内提升自己，而不是阻止你完整理解整个项目。

　　6、结论

　　整篇文章的重点在于，对项目进行必要了解，然后进行快速交付。你可以在不降低代码质量的前提下做到这一点。

　　如果要修复bug，那么迅速定位并修复。可以在必要的时候使用运行时分析工具。如果要新增特性，那么可以寻找类似特性，理解流程（在必要的时候使用工具）并编写。

　　或许这些听起来很简单，但是实用吗？当然。前提是你有良好的Java技术，以及对框架足够了解，然后才能先修改代码，再分析变更所产生的影响。分析变更所产生的影响比实施变需要更多技巧。你可能需要高级开发人员协助你分析变更影响。

　　大约有50%的IT可操作预算用于简单的bug修复和功能增强。文中的建议对于在维护活动中节省经费应当还是很有帮助的。