原标题： Java开发中最流行的最广泛的大型项目实战技巧？
假设您开发并维护了一个包含2000个类并使用许多框架的Java开发人员。 怎么理解这些代码？ 在典型的Java企业项目团队中，大多数高级工程师看起来都很忙。 文档也很少。 必须尽快交付交付件，并向项目团队证明自己的能力。 你怎么处理这种情况？ 此文本为启动新项目的Java开发人员提供了一些建议。
1、不想一下子理解整个项目
仔细想想为什么理解项目代码是首要的。 大多数情况下，系统会提示您修复错误或增强系统的现有功能。 你要做的第一件事，不是了解整个项目的框架。 在维护项目时，这样(了解整个项目体系结构)可能会给你带来很大的压力。
即使是有10年可靠编程经验的Java开发人员也可能不了解项目的核心工作方式。 但是，他们可能已经在这个项目上工作了一年多。 请假设不是原始开发者。 例如，对于验证机制或事务管理机制。
他们是怎么做到的？ 他们对自己负责的部分很了解，能为集团提供价值。 每天的交货价值，比知道以后有没有不知道的东西重要得多。
2、关注尽快提供价值
你决定了对你的项目框架的理解的热情吗？ 完全不同。 我只是要求你提前交货价值。 一旦你开始了项目，建立了开发环境，不管他的规模如何，交付什么都不应该花一两周的时间。 如果你是一个有经验的程序员，两周没有任何交货，你的经理怎么知道你是真的在工作，还是在看新闻？
所以交货可以让大家轻松。 不要认为在创造有价值的交付件之前必须了解整个项目。 这是完全错误的。 添加java验证码对企业很有价值，经理可以通过你的交货达到对你的信任。 这样可以向高级领导证明你的贡献和员工价值。
在每天修正错误并强化功能的过程中，可以慢慢开始理解项目的框架。 不要低估了解系统的各个方面所花的时间。 花3-4天了解认证机制，花2-3天了解事物管理。 这些都依靠以往类似项目的经验，但关键是需要时间才能完全理解。 要在日常工作中抽出时间，不要向经理要求特定的时间。
查找项目中是否存在持续维护的单元测试用例。 有效的单元测试用例是理解大型项目代码的好方法。 单元测试有助于理解代码片段，包括单个单元的外部接口(如何调用单元并返回其内容)及其内部实现。 调试单元测试比调试整个实际用例要简单得多。 加-群-860170416-和大神一起沟通学习。 一旦充分理解了内容，就写笔记，画类图、时序图、数据模型图，供你和将来的其他开发人员维护。
3、维持大型项目所需的技能
你能从事现在的工作，一定已经有良好的java技术了。 谈谈你在新项目中能顺利进行的其他技能吧。 大部分时间，你在项目中的任务是修复bug和增强功能。
有两个重要技能可以帮助维护大的项目代码。
3.1能够快速发现所需的类
在任何维护任务中，如果要修复错误或增强功能，第一个操作是标识在当前正在修复或增强的用例中调用的类。 重要的玉米定位于需要修复或强化的类/方法，完成了一半。
3.2可以分析变更的影响
重要的玉米在完成必要的修改和强化工作后，最重要的是确保你的修改没有破坏代码的其他部分。 必须使用你对java技术和其他框架的理解来找出更改可能影响的部分。 有两个简单的例子详细说明了最后提到的情况。
a ) a类equals ) )方法更改后，调用contains ) )方法将会受到影响，后者将保护a实例的列表。 在缺乏Java知识的情况下，很难考虑这样的影响。 b )在web项目中，假设“用户id”存储在会话中。 新程序员可以将信息添加到“user id”中作为错误修复方法，但不知道会影响与“user id”相关的用例。
重要的玉米提高了上述两种技能，尽管你对项目不太了解，大多数维护任务都会变得简单。 如果要修复错误，请识别并修复该错误，以确保更改不会破坏项目的其他部分。 如果强化或追加特性的话，基本上只是模仿现有的特性并使用相似的设计。
在网上银行项目中，“查看账户概要”和“查看交易历史记录”的设计为什么需要很大的差异呢？ 了解“查看帐户摘要”的设计后，就可以模仿“查看交易历史记录”功能进行开发。
关于错误的修正和扩展，不需要完全理解所有2000个类的工作内容和代码是如何工作和推动系统的。 上述技能可以帮助您快速识别需要修改的代码部分，并使用java和框架技能进行修改，以确保更改不会破坏项目的其他部分并交付，尽管您只知道项目的一小部分设计。
4、使用工具找出必要的变更内容和变更带来的影响
我们要继续尽快交货的主题，通过尽可能少的理解项目，但是要寻找能帮助你尽快实施交货的工具来辅助。
4.1快速发现需要更改内容的工具
无论是修复错误还是扩展系统，您都必须首先找到该用例调用的您应该修改的类和方法。 要理解一个用例的工作方式，基本上有两种方法：静态代码分析和运行时分析。
分析源代码并扫描所有代码，以显示类之间的关系。 市场上有很多设备和工具。 比
如：Architexa， AgileJ， UModel， Poseidon等。所有的静态代码分析工具缺点在于无法确切展示用例中类或方法的运行时调用情况。因此Java新加入了特性，如回调机制(callback patterns)。如静态分析工具无法推断出当页面提交按钮被点击时哪个Servlet被调用了。
运行时分析工具能够展示类和方法在用例运行时的状态。工具包括：MaintainJ， Diver，jSonde，Java Call Tracer等。这些工具可以捕获运行时的堆栈状态，并以此为一个用例生成序列图和类图。
序列图展示了该用例在运行时所有调用的方法。若你在修复一个bug，那这个bug很可能就是这些被调用的方法之一。
若你在增强已有功能，利用序列图理解调用流程然后再修改。可能是新增一个验证，修改DAO等。
若你在新增功能，找到一些相似的特性，利用序列图理解调用流程然后模仿开发新功能。
要小心挑选运行时分析工具。信息过多是这类工具的主要问题。选择一些提供简单过滤无效信息并能够方便的查看各种视图的工具。
4.2 迅速发现需要变更内容的工具
若单元测试有效，可以通过运行单元测试发现变更有没有破坏其他测试用例。有效维护并且覆盖大型企业应用的单元测试还是比较少的。下面有一些针对该情况的工具。
仍然是有两种技术静态代码分析和运行时分析可以使用。市场中有很多静态代码分析工具可用。如：Lattix, Structure101, Coverity, nWire and IntelliJ’s DSM。
给定一个变更后的类，上述工具均可识别对该类存在依赖的类的集合。开发者需要根据这些信息“猜测”可能产生影响的用例，因为这些工具无法展示运行时类之间的调用关系。
市 场上的可以用于运行时影响分析的工具并不多，除了MaintainJ。MaintainJ先捕获在一个用例中调用的所有类和方法。当所有用例的上述信息都 被捕获之后，就很容易发现类的变更对用例的影响。MaintainJ能够有效工作的前置条件就是项目的所有用例都应当先运行一遍，以便能够获得运行时的依 赖关系。
总之，目前你在迅速准确分析变更影响方面，还是可以从工具中获得有限的帮助。首先根据需要实施一些影响分析，然后根据自己或小组其他高级成员评审来判断变更的影响。你可能需要上面提到的工具对你的判断进行反复确认。
5、对上述内容的两个忠告5.1不要降低代码质量
为了快速交付，所以没有全盘理解架构，但绝不能以降低代码质量为条件。下面是一些你可能因为只考虑快速交付而引发的代码质量问题。
因 为修改代码涉及到很多的依赖，所以新增代码相对而言风险较小。例如，有5个用例都调用了某个方法。为了改进某个用例，你需要修改这个方法的实现。最简单的 做法就是复制这个方法，重命名，然后在改进的用例中调用新方法。千万不要这么做。代码冗余绝对是非常有害的。尝试对方法进行包装或者重写，甚至是直接修 改，然后重新测试所有用例，通常停下来想一想，然后亲手去实施，是一个比较好的方式。
另一个例子是将“private”方法改为“public”，使得别的类也可以调用。尽量不要将非必须的部分暴露出来。假如为了更好的设计需要重构，就应当着手去做。
大部分应用都有确定的结构和模式来实施。修复或增强程序时，确认你没有偏离这样的模式。若对约定不确定，请其他的高级开发者来审核你的变更。若你必须做一些违背约定的实施，尽量放置于一个规模较小的类中(一个200行代码的类中的私有函数应当不会影响应用的整体设计)
5.2 不要停止深入理解项目架构
按 照文章列出的方式，假设你能够在对项目了解较少的情况下进行交付并以此持续下去，可能你会停止对项目架构的深入了解。这样从长远角度来说对你的职业生涯没 有帮助。重要的玉米的经验增加时，你应当承担比较大的模块任务。如构建一个完整的新特性或者修改项目的一些基础设计等较大的改进。重要的玉米能够做这些改进时，你对项 目的整体架构应该相当了解。文中列举的方法是让你在最短的时间内提升自己，而不是阻止你完整理解整个项目。
6、 结论
整篇文章集中在对项目进行必要了解的前提下进行快速交付。你可以在不降低代码质量的前提下这么做。
若修复一个bug，迅速定位并修复。有必要可以使用运行时分析工具。若新增一个特写，可以寻找相似特写，理解流程(有必要使用工具)并编写。
或许这些听起来很简单，但是实用吗？当然。但前提是你有良好的java技术以及对框架足够了解才能先修改代码，然后对变更影响进行分析。对变更影响的分析比实施变更需要更多的技巧。你可能需要高级开发人员协助你分析变更影响。
大约有50%的IT可操作预算用于简单的bug修复和功能增强。根据文中的建议，对于维护活动中的经费的节省应当还是很有帮助的。返回搜狐，查看更多
责任编辑：