给开发维护大型项目开发者的建议

假设你是正在开发和维护一个包含2000个类并使用了不少框架的Java开发人员。你要如何理解这些代码？在一个典型的Java企业项目小组中，大 部分可以帮你的高级工程师看起来都很忙。文档也不多。你须要尽快交付成果，并向项目组证实本身的能力。你会如何处理这种情况？这篇文字为开始一个新项目的 Java开发者提供了一些建议。

0. 不要试图一会儿搞懂整个项目

好好考虑一下，为何理解项目代码是第一位的？大部分状况是你被要求修复一个bug或者增强系统已有功能。你要作的第一件事情不是理解整个项目的架构。当对项目进行维护时，这样（理解整个项目架构）可能会对你形成巨大的压力。

即使是有着10年可靠编程经验的Java开发者可能也没有理解项目的核心工做机制，尽管他们可能已经在这个项目工做超过一年（假设他们并不是原始开发人员）。好比，对于认证机制或事务管理机制。

他们是怎么作的？他们对于本身负责的部分很是了解，而且可以交付价值给小组。天天的交付价值远比了解一些之后还不肯定有没有的东西重要的多。

1. 关注于尽快交付价值

那我是否认了你对于项目架构理解的热情了么？彻底不。我只是要求你尽早的交付价值，一旦你开始一个项目，搭建了开发环境，你就不该该花一两周时间才交付什么，不管他的规模大小。假如你是一个有经验的程序员却两周都没有任何交付，你的经理怎么会知道你是真的在工做仍是在看新闻。

因此交付可使你们都轻松起来。不要认为你可以作有价值的交付前必须理解整个项目。这是彻底错误的。加一段javascript的验证代码对业务就颇有价值，经理可以经过你的交付达到对你的信任。这样可以向上级领导证实你的贡献以及员工价值。

日复一日，在你不断修复bug及加强功能以后，就可以慢慢开始理解项目架构。不要低估对系统方方面面理解时须要花费的时间。花3-4天理解认证机 制，2-3天理解事物管理。这些都是依靠以前的类似项目的经历，但关键仍是要花时间才能透彻的理解。要在平常工做中挤出时间，不要向经理要求特定的时间来 作这些。

找找项目是否有一些不断维护的单元测试用例。有效的单元测试用例是理解大型项目代码的很好途径。单元测试可以帮助理解代码片断，包括一个单元的外部接口（单元如何被调用以及返回内容）及其内部实现（调试单元测试比调试整个实际用例简单许多）。

你若是可以很好的理解一些内容，写一些笔记，或者画一些类图、时序图、数据模型图，以便你或往后其余的开发者维护。

2. 维护大型项目所必须的技能

你能从事当前的工做，必然已经具备良好的java技术。咱们来谈谈可以让你在新项目中良好表现的其余技能。大部分时间，你在项目中的任务是修复bug和加强功能。

有两项很重要的技能可以协助你维护大型项目代码。

2.1 可以迅速发现须要的类

在任何维护活动中，不管是修复bug或加强功能，第一个动做就是识别出当前修复或加强的用例中调用的类。当你定位到须要修复或加强的类/方法，就已经完工了一半。

2.2 可以分析变动的影响

当你在完成必要的修改或加强工做后，最重要的就是要确认你的修改没有破坏代码的其余部分。你要用你的java技术及对其余框架的理解找出变动可能影响的部分。下面有两个简单的例子详细描述了最后说起的状况：

a）当类A的equals()方法变动后，调用一个保护A实例的List的contains()方法时就会被影响到。若Java知识不够，很难考虑到这样的影响。

b）在一个web项目中，咱们假设“user id”保存在session中。一个新入程序员可能在“user id”中加入一些信息做为bug修复的方法，可是殊不知道会影响到那些关联“user id”的用例。

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

在一个在线银行项目中，为何“查看帐户摘要”和“查看交易历史”的设计须要巨大的差异呢？若是你理解了“查看帐户摘要”的设计，彻底能够模仿开发出“查看交易历史”的功能。

就修复bug和加强来讲，你没必要彻底理解全部2000个类的工做内容和代码如何运行来推进系统。你如有上面的技能，就能很快定位须要修改的代码的部分，使用良好的java和框架技能修复，保证变动不会破坏项目的其余部分并交付，尽管你可能只知道一小部分项目的设计。

3. 使用工具找到须要的变动内容以及变动产生的影响

继续咱们尽快交付的主题，你应当寻找那些可以经过尽可能少的了解项目但能帮助你尽快实施交付的工具做为辅助。

3.1 迅速发现须要变动内容的工具

不管是修复bug仍是系统加强，首先都要找到该用例调用的你须要修改的类及方法。基本有两种方式理解一个用例的工做方式，静态代码分析和运行时分析。

源码分析统计扫描全部代码而且展现类之间的关系。市场上有不少设备与工具。好比：Architexa， AgileJ， UModel， Poseidon等。

全部的静态代码分析工具缺点在于没法确切展现用例中类或方法的运行时调用状况。所以Java新加入了特性，如回调机制（callback patterns）。如静态分析工具没法推断出当页面提交按钮被点击时哪一个Servlet被调用了。

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

序列图展现了该用例在运行时全部调用的方法。若你在修复一个bug，那这个bug极可能就是这些被调用的方法之一。

若你在加强已有功能，利用序列图理解调用流程而后再修改。多是新增一个验证，修改DAO等。

若你在新增功能，找到一些类似的特性，利用序列图理解调用流程而后模仿开发新功能。

要当心挑选运行时分析工具。信息过可能是这类工具的主要问题。选择一些提供简单过滤无效信息并可以方便的查看各类视图的工具。

3.2 迅速发现须要变动内容的工具

若单元测试有效，能够经过运行单元测试发现变动有没有破坏其余测试用例。有效维护而且覆盖大型企业应用的单元测试仍是比较少的。下面有一些针对该状况的工具。

仍然是有两种技术静态代码分析和运行时分析可使用。市场中有不少静态代码分析工具可用。如：Lattix, Structure101, Coverity, nWire and IntelliJ’s DSM。

给定一个变动后的类，上述工具都可识别对该类存在依赖的类的集合。开发者须要根据这些信息“猜想”可能产生影响的用例，由于这些工具没法展现运行时类之间的调用关系。

市场上的能够用于运行时影响分析的工具并很少，除了MaintainJ。MaintainJ先捕获在一个用例中调用的全部类和方法。当全部用例的上 述信息都被捕获以后，就很容易发现类的变动对用例的影响。MaintainJ可以有效工做的前置条件就是项目的全部用例都应当先运行一遍，以便可以得到运 行时的依赖关系。

总之，目前你在迅速准确分析变动影响方面，仍是能够从工具中得到有限的帮助。首先根据须要实施一些影响分析，而后根据本身或小组其余高级成员评审来判断变动的影响。你可能须要上面提到的工具对你的判断进行反复确认。

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

4.1 不要下降代码质量

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

由于修改代码涉及到不少的依赖，因此新增代码相对而言风险较小。例如，有5个用例都调用了某个方法。为了改进某个用例，你须要修改这个方法的实现。 最简单的作法就是复制这个方法，重命名，而后在改进的用例中调用新方法。千万不要这么作。代码冗余绝对是很是有害的。尝试对方法进行包装或者重写，甚至是 直接修改，而后从新测试全部用例，一般停下来想想，而后亲手去实施，是一个比较好的方式。

（ 伯乐在线配图）

另外一个例子是将“private”方法改成“public”，使得别的类也能够调用。尽可能不要将非必须的部分暴露出来。假如为了更好的设计须要重构，就应当着手去作。

大部分应用都有肯定的结构和模式来实施。修复或加强程序时，确认你没有偏离这样的模式。若对约定不肯定，请其余的高级开发者来审核你的变动。若你必须作一些违背约定的实施，尽可能放置于一个规模较小的类中（一个200行代码的类中的私有函数应当不会影响应用的总体设计）

4.2 不要中止深刻理解项目架构

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

5. 结论

整篇文章集中在对项目进行必要了解的前提下进行快速交付。你能够在不下降代码质量的前提下这么作。

若修复一个bug，迅速定位并修复。有必要可使用运行时分析工具。若新增一个特写，能够寻找类似特写，理解流程（有必要使用工具）并编写。

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

大约有50%的IT可操做预算用于简单的bug修复和功能加强。根据文中的建议，对于维护活动中的经费的节省应当仍是颇有帮助的。

做者 Choudary Kothapalli 也是 MaintainJ 项目的创建者。