程序员开发大型应用程序的技巧(2)

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

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

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

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

　　4.2 发现变更产生影响的工具

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

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

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

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

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

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

　　5.1 不要降低代码质量

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

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

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

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

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

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

　　6. 结论

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

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

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

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

原文转自：http://www.ltesting.net