认识达内从这里开始

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

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

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

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

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

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

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

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

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

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

2.不要降低代码质量

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

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

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

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

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

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

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

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

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

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

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

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