假设你正在开发和维护一个拥有2000个类并使用许多框架的Java开发者。您将如何理解这些代码？在一个典型的Java企业项目团队中，能帮你的高级工程师大多看起来很忙。文档也很少。您需要尽快交付结果并向项目团队证明您的能力。你会如何处理这种情况？本文为开始新项目的Java开发人员提供了一些建议。1.不要试图一下子理解整个项目。想想看。为什么理解项目代码最重要？在大多数情况下，您会被要求修复错误或增强系统的现有功能。你需要做的第一件事就是不了解整个项目的架构。这（了解项目的整体架构）在维护项目时会给你带来很大的压力。即使是具有10年扎实编程经验的Java开发人员也可能不了解该项目的核心工作机制，即使他们可能已经在该项目上工作了一年多（假设他们不是最初的开发人员）。例如，用于身份验证机制或事务管理机制。他们如何做他们对自己的职责有很好的理解，可以为团队创造价值。每天交付价值远比知道一些你将来可能不知道的东西重要得多。2.专注于尽快交付价值。我是在否定你理解项目架构的热情吗？绝对不。我只是要求你尽早交付价值。一旦您开始一个项目并设置了一个开发环境，您不应该花一两个星期来交付一些东西，无论它是大是小。如果你是一位经验丰富的程序员，并且你已经两周没有交付任何东西，你的经理怎么知道你是否真的在工作或看新闻。所以交付可以让每个人都更轻松。不要认为您必须了解整个项目才能做出有价值的可交付成果。这是完全错误的。加一段javascript验证码对业务来说是很有价值的，经理可以通过你的交付获得对你的信任。这将向上级展示您的贡献和员工价值。日复一日，当你不断修复错误和增强功能时，你可以慢慢开始了解项目架构。不要低估了解系统各个方面所花费的时间。花3-4天了解认证机制，2-3天了解交易管理。这些都是基于之前类似项目的经验，但关键是要花时间去理解透彻。在你的日常工作中腾出时间，不要向你的经理要求具体的工作时间。查看项目是否有一些持续维护的单元测试用例。有效的单元测试用例是理解大型项目代码的好方法。单元测试有助于理解代码片段，包括单元的外部接口（单元如何调用以及返回什么）及其内部实现（调试单元测试比调试整个实际用例要容易得多）。如果你能很好地理解一些内容，写一些笔记，或者画一些类图、时序图、数据模型图，供你或其他开发人员日后维护。3.维护大型项目所需的技能。能从事现在的工作，一定要有很好的java技术。让我们谈谈可以让您在新项目中表现出色的其他技能。大多数时候，您在项目中的任务是修复错误和增强功能。有两个非常重要的技能可以帮助您维护大型项目代码。3.1能够快速发现需要的类在任何维护活动中，无论是修复错误还是增强功能，首先要做的就是识别当前修复或增强用例中调用的类。当您找到需要修复或增强的类/方法时，就完成了一半的工作。3.2能够分析变化的影响当你完成了必要的修改或增强后，最重要的是确认你的修改没有破坏代码的其他部分。您需要使用您的java技术和对其他框架的了解来找出更改可能会影响哪些部分。下面两个简单的例子详细描述了***中提到的情况：a)当类A的equals()方法改变时，调用保护A实例的List的contains()方法时会受到影响.如果Java知识不够，很难考虑这样的影响。b)在一个web项目中，我们假设“用户id”保存在session中。新手程序员可能会在“userid”中添加一些信息作为修复错误的方法，但不知道这会影响与“userid”关联的用例。当你提高以上两项技能后，即使你对项目不是很了解，大多数维护工作也会变得容易得多。如果你修复了一个错误，你就找到并修复了这个错误，并确保更改不会破坏项目的其他部分。如果你增强或添加一个功能，基本上你只需要使用类似的设计来模仿现有的功能。在一个网上银行项目中，为什么“查看账户摘要”和“查看交易历史”的设计需要如此不同？如果你了解“查看账户摘要”的设计，你完全可以模仿和开发“查看交易历史”的功能。在错误修复和增强方面，您不必完全了解所有2000个类的工作原理以及代码如何驱动系统。如果你具备以上技能，你可以快速定位到需要修改的代码部分，利用良好的java和framework技能进行修复，保证改动不会破坏项目的其他部分并交付，虽然你可能只知道项目设计的一小部分。4.使用工具找到所需的变更和变更的影响继续我们尽快交付的主题，您应该寻找可以帮助您尽快实施交付的工具，同时尽可能少地了解项目.4.1快速发现需要修改内容的工具无论是修复bug还是增强系统，首先要找到用例调用的需要修改的类和方法。基本上有两种方法可以理解用例如何工作，静态代码分析和运行时分析。源代码分析统计扫描所有代码并显示类之间的关系。市场上有许多设备和工具。例如：Architexa、AgileJ、UModel、Poseidon等。所有静态代码分析工具的缺点是无法准确显示用例中类或方法的运行时调用。因此，Java新增了回调机制（callbackpatterns）等特性。例如，静态分析工具无法推断出单击页面提交按钮时调用了哪个Servlet。运行时分析工具可以显示用例运行时类和方法的状态。工具包括：MaintainJ、Diver、jSonde、JavaCallTracer等。这些工具捕获运行时堆栈状态，并使用它为用例生成序列图和类图。序列图显示了用例在运行时调用的所有方法。如果您正在修复错误，则错误很可能是这些被调用的方法之一。如果您正在增强现有功能，请使用序列图了解调用流程，然后对其进行修改。可能是加一个验证，修改DAO等。如果是加新功能，找一些类似的功能，用时序图了解调用流程，然后模拟新功能的开发。仔细选择您的运行时分析工具。信息过多是此类工具的主要问题。选择能够轻松过滤无效信息并轻松访问各种视图的工具。4.2快速发现需要更改的工具如果单元测试有效，您可以运行单元测试以找出更改是否破坏了其他测试用例。有效维护并覆盖大型企业应用程序的单元测试相对较少。以下是针对这种情况的一些工具。还有两种技术可以使用静态代码分析和运行时分析。市场上有许多静态代码分析工具。如：Lattix、Structure101、Coverity、nWire和IntelliJ的DSM。给定一个更改后的类，这些工具首先会识别依赖于该类的一组类。开发人员需要根据这些信息“猜测”可能产生影响的用例，因为这些工具无法在运行时显示类之间的调用关系。市面上能做运行时影响分析的工具并不多，MaintainJ除外。MaintainJ首先捕获用例中调用的所有类和方法。当捕获所有用例的上述信息时，很容易发现类变化对用例的影响。MaintainJ有效工作的前提是项目的所有用例都应该运行一次以获得运行时依赖。总而言之，目前您可以从工具中获得有限的帮助来快速准确地分析变更的影响。首先根据需要执行一些影响分析，然后根据您自己或团队中其他高级成员审查变更来判断变更的影响。您可能需要使用上述工具交叉检查您的判断。5.对以上内容的两个建议5.1不要降低代码质量为了快速交付，所以对架构没有整体的了解，但一定不能以降低代码质量为条件。以下是您可能只考虑快速交付而导致的一些代码质量问题。因为修改代码涉及很多依赖，添加新代码的风险相对较小。例如，有5个用例都调用了某个方法。为了改进某个用例，您需要修改此方法的实现。最简单的方法是复制方法，重命名它，然后在改进的用例中调用新方法。永远不要这样做。代码冗余肯定是非常有害的。尝试包装或重写方法，甚至直接修改它，然后重新测试所有用例。停下来想一想，然后自己实施通常是更好的方法。再比如把一个“私有”的方法改成“公共”，这样其他类也可以调用它。尽量不要暴露不必要的部分。如果你需要重构以获得更好的设计，你应该这样做。大多数应用程序都有定义的结构和实施模式。在修复或增强程序时，请确保您没有偏离这些模式。如果您不确定这些约定，请让其他高级开发人员审查您的更改。如果一定要做一些违背约定的实现，尽量放在小一点的类中（200行代码的类中一个私有函数应该不会影响应用的整体设计）5.2不要停止对项目的理解文章中列出的体系结构你这样做的方式，假设你可以在对项目知之甚少的情况下交付并继续这样做，你可能会停止对项目体系结构的深入理解。从长远来看，这对你的职业生涯没有帮助。随着经验的增加，你应该承担更大的模块任务。较大的改进，例如构建一个完整的新功能或修改项目的一些基本设计。当你能够进行这些改进时，你应该对项目的整体结构有了相当的了解。本文列出的方法是为了让你在最短的时间内提升自己，而不是阻止你全面了解整个项目。6.结语整篇文章着眼于在对项目有必要了解的前提下快速交付。您可以在不影响代码质量的情况下做到这一点。如果修复了bug，请快速定位并修复它。如有必要，可以使用运行时分析工具。如果你增加一个新功能，你可以找到类似的功能，了解过程（工具是必要的）并编写它。也许这些听起来很简单，但是实用吗？当然。但是前提是你有很好的java技术，对框架有足够的了解，先修改代码，再分析修改的影响。分析变更的影响需要比实施变更更多的技能。您可能需要高级开发人员来协助您分析变更的影响。大约50%的IT可操作预算用于简单的错误修复和功能增强。根据论文中的建议，在维护活动中省钱应该还是很有帮助的。
