假设你是正在开发和维护一个包含2000个类并使用了很多框架的Java开发者。你要如何理解这些代码？在一个典型的Java企业项目小组中，大部 分能够帮你的高级工程师看起来都很忙。文档也很少。你需要尽快交付成果，并向项目组证明自己的能力。你会如何处理这种状况？这篇文字为开始一个新项目的 Java开发者提供了一些建议。
1、不要试图一下子搞懂整个项目
好好考虑一下，为什么理解项目代码是第一位的？大部分情况是你被要求修复一个bug或者加强系统已有功能。你要做的第一件事情不是理解整个项目的架构。当对项目进行维护时，这样（理解整个项目架构）可能会对你造成巨大的压力。即便是有着10年可靠编程经验的Java开发者可能也没有理解项目的核心工作机制，尽管他们可能已经在这个项目工作超过一年（假设他们并非原始开发人员）。比如，对于认证机制或事务管理机制。他们是怎么做的？他们对于自己负责的部分非常了解，并且能够交付价值给小组。每天的交付价值远比了解一些以后还不确定有没有的东西重要的多。
2、关注于尽快交付价值
那是否定了你对于项目架构理解的热情了么？完全不。只是要求你尽早的交付价值，一旦你开始一个项目，搭建了开发环境，你就不应该花一两周时间才交付什么，无论他的规模大小。假如你是一个有经验的程序员却两周都没有任何交付，你的经理怎么会知道你是真的在工作还是在看新闻。所以交付可以使大家都轻松起来。不要认为你能够做有价值的交付前必须理解整个项目。这是完全错误的。加一段javascript的验证代码对业务就很有价值，经理能够通过你的交付达到对你的信任。这样能够向上级领导证明你的贡献以及员工价值。日复一日，在你不断修复bug及增强功能之后，就能够慢慢开始理解项目架构。不要低估对系统方方面面理解时需要花费的时间。花3-4天理解认证机 制，2-3天理解事物管理。这些都是依靠之前的相似项目的经历，但关键还是要花时间才能透彻的理解。要在日常工作中挤出时间，不要向经理要求特定的时间来做这些。找找项目是否有一些不断维护的单元测试用例。有效的单元测试用例是理解大型项目代码的很好途径。单元测试能够帮助理解代码片段，包括一个单元的外部接口（单元如何被调用以及返回内容）及其内部实现（调试单元测试比调试整个实际用例简单许多）。你如果能够很好的理解一些内容，写一些笔记，或者画一些类图、时序图、数据模型图，以便你或日后其他的开发者维护。
3、维护大型项目所必须的技能
你能从事当前的工作，必然已经具有良好的java技术。我们来谈谈能够让你在新项目中良好表现的其他技能。大部分时间，你在项目中的任务是修复bug和增强功能。有两项很重要的技能能够协助你维护大型项目代码。
3.1能够迅速发现需要的类
在任何维护活动中，无论是修复bug或增强功能，第一个动作就是识别出当前修复或增强的用例中调用的类。当你定位到需要修复或增强的类/方法，就已经完工了一半。
3.2能够分析变更的影响
当你在完成必要的修改或增强工作后，最重要的就是要确认你的修改没有破坏代码的其他部分。你要用你的java技术及对其他框架的理解找出变更可能影响的部分。下面有两个简单的例子详细描述了最后提及的情况： a）当类A的equals()方法变更后，调用一个保护A实例的List的contains()方法时就会被影响到。若Java知识不够，很难考虑到这样的影响。
b）在一个web项目中，我们假设“user id”保存在session中。一个新入程序员可能在“user id”中加入一些信息作为bug修复的方法，但是却不知道会影响到那些关联“user id”的用例。
当你提高了如上两个技能，尽管你对项目不是非常了解，但大部分的维护任务会变得简单很多。若你修复一个bug，你会定位并修复这个bug，并且保证变更不会破坏项目的其他部分。若你增强或加入一个特性，基本上你只需要模仿现有的特性使用相似的设计。在一个在线银行项目中，为什么“查看账户摘要”和“查看交易历史”的设计需要巨大的差别呢？如果你理解了“查看账户摘要”的设计，完全可以模仿开发出“查看交易历史”的功能。就修复bug和增强来说，你不必完全理解所有2000个类的工作内容和代码如何运行来推动系统。你若有上面的技能，就能很快定位需要修改的代码的部分，使用良好的java和框架技能修复，保证变更不会破坏项目的其他部分并交付，尽管你可能只知道一小部分项目的设计。
|
|
收藏
淘帖
踩
