0. 不要试图一下子搞懂整个目
好好考虑一下，Z么理解项目代码是W一位的Q大部分情况是你被要求修复一个bug或者加强系l已有功能。你要做的第一件事情不是理解整个项目的架构。当寚w目进行维护时Q这P理解整个目架构Q可能会对你造成巨大的压力?/p>
即便是有着10q可靠编E经验的Java开发者可能也没有理解目的核心工作机Ӟ管他们可能已经在这个项目工作超q一q_假设他们q原始开发h员）。比如，对于认证机制或事务管理机制?/p>
他们是怎么做的Q他们对于自p责的部分非常了解Qƈ且能够交付h值给组。每天的交付价D比了解一些以后还不确定有没有的东襉K要的多?/p>
1. x于尽快交付h?/strong>
那我是否定了你对于项目架构理解的热情了么Q完全不。我只是要求你尽早的交付价|一旦你开始一个项目，搭徏了开发环境，你就不应该花一两周旉才交付什么，无论他的规模大小。假如你是一个有l验?span class="wp_keywordlink" style="padding-right: 0px; padding-left: 0px; padding-bottom: 0px; margin: 0px; padding-top: 0px">E序?/a>却两周都没有M交付Q你的经理怎么会知道你是真的在工作q是在看新闻?/p>
所以交付可以大家都轻松v来。不要认Z能够做有价值的交付前必ȝ解整个项目。这是完全错误的。加一Djavascript的验证代码对业务很有h|l理能够通过你的交付辑ֈ对你的信仅R这栯够向上领导证明你的贡献以及员工价倹{?/p>
日复一日，在你不断修复bug及增强功能之后，p够慢慢开始理解项目架构。不要低估对pȝҎ面面理解旉要花费的旉。花3-4天理解认证机Ӟ2-3天理解事物管理。这些都是依靠之前的怼目的经历，但关键还是要花时间才能透彻的理解。要在日常工作中挤出旉Q不要向l理要求特定的时间来做这些?/p>
找找目是否有一些不断维护的单元试用例。有效的单元试用例是理解大型项目代码的很好途径。单元测试能够帮助理解代码片D，包括一个单元的外部接口Q单元如何被调用以及q回内容Q及其内部实玎ͼ调试单元试比调试整个实际用例简单许多）?/p>
你如果能够很好的理解一些内容，写一些笔讎ͼ或者画一些类图、时序图、数据模型图Q以便你或日后其他的开发者维护?/p>
2. l护大型目所必须的技?/strong> 你能从事当前的工作，必然已经h良好的java技术。我们来谈谈能够让你在新目中良好表现的其他技能。大部分旉Q你在项目中的Q务是修复bug和增强功能?/p>
有两很重要的技能能够协助你l护大型目代码?/p>
2.1 能够q速发现需要的c?/strong> 在Q何维护活动中Q无论是修复bug或增强功能，W一个动作就是识别出当前修复或增强的用例中调用的cR当你定位到需要修复或增强的类/ҎQ就已经完工了一半?/p>
2.2 能够分析变更的媄?/strong> 当你在完成必要的修改或增强工作后Q最重要的就是要认你的修改没有破坏代码的其他部分。你要用你的java技术及对其他框架的理解扑և变更可能影响的部分。下面有两个单的例子详细描述了最后提及的情况Q?/p>
aQ当cA的equals()Ҏ变更后，调用一个保护A实例的List的contains()Ҏ时就会被影响到。若Java知识不够Q很难考虑到这L影响?/p>
bQ在一个web目中，我们假设“user id”保存在session中。一个新入程序员可能?#8220;user id”中加入一些信息作为bug修复的方法，但是却不知道会媄响到那些兌“user id”的用例?/p>
当你提高了如上两个技能，管你对目不是非常了解Q但大部分的l护d会变得简单很多。若你修复一个bugQ你会定位ƈ修复q个bugQƈ且保证变更不会破坏项目的其他部分。若你增强或加入一个特性，基本上你只需要模仿现有的Ҏ用相似的设计?/p>
在一个在UK行项目中Qؓ什?#8220;查看账户摘要”?#8220;查看交易历史”的设计需要巨大的差别呢？如果你理解了“查看账户摘要”的设计，完全可以模仿开发出“查看交易历史”的功能?/p>
׃复bug和增强来_你不必完全理解所?000个类的工作内容和代码如何q行来推动系l。你若有上面的技能，p很快定位需要修改的代码的部分，使用良好的java和框架技能修复，保证变更不会破坏目的其他部分ƈ交付Q尽你可能只知道一部分项目的设计?/p>
3. 使用工具扑ֈ需要的变更内容以及变更产生的媄?/strong> l箋我们快交付的主题，你应当寻N些能够通过量的了解目但能帮助你尽快实施交付的工具作ؓ辅助?/p>
3.1 q速发现需要变更内容的工具 无论是修复bugq是pȝ增强Q首先都要找到该用例调用的你需要修改的cdҎ。基本有两种方式理解一个用例的工作方式Q静态代码分析和q行时分析?/p>
源码分析l计扫描所有代码ƈ且展C类之间的关pR市Z有很多设备与工具。比如：ArchitexaQ?AgileJQ?UModelQ?Poseidon{?/p>
所有的静态代码分析工L点在于无法确切展C用例中cLҎ的运行时调用情况。因此Java新加入了Ҏ，如回调机Ӟcallback patternsQ。如静态分析工h法推断出当页面提交按钮被点击时哪个Servlet被调用了?/p>
q行时分析工兯够展C类和方法在用例q行时的状态。工具包括：MaintainJQ?DiverQjSondeQJava Call Tracer{。这些工具可以捕莯行时的堆栈状态，q以此ؓ一个用例生成序列图和类图?/p>
序列囑ֱCZ该用例在q行时所有调用的Ҏ。若你在修复一个bugQ那q个bug很可能就是这些被调用的方法之一?/p>
若你在增强已有功能，利用序列囄解调用流E然后再修改。可能是新增一个验证，修改DAO{?/p>
若你在新增功能，扑ֈ一些相似的Ҏ，利用序列囄解调用流E然后模仿开发新功能?/p>
要小心挑选运行时分析工具。信息过多是q类工具的主要问题。选择一些提供简单过滤无效信息ƈ能够方便的查看各U视囄工具?/p>
3.2 q速发现需要变更内容的工具 若单元测试有效，可以通过q行单元试发现变更有没有破坏其他测试用例。有效维护ƈ且覆盖大型企业应用的单元试q是比较的。下面有一些针对该情况的工兗?/p>
仍然是有两种技术静态代码分析和q行时分析可以用。市Z有很多静态代码分析工具可用。如QLattix, Structure101, Coverity, nWire and IntelliJ’s DSM?/p>
l定一个变更后的类Q上q工具均可识别对该类存在依赖的类的集合。开发者需要根据这些信?#8220;猜测”可能产生影响的用例，因ؓq些工具无法展示q行时类之间的调用关pR?/p>
市场上的可以用于q行时媄响分析的工具q不多，除了MaintainJ。MaintainJ先捕获在一个用例中调用的所有类和方法。当所有用例的上述信息都被捕获之后Q就很容易发现类的变更对用例的媄响。MaintainJ能够有效工作的前|条件就是项目的所有用例都应当先运行一遍，以便能够获得q行时的依赖关系?/p>
MQ目前你在迅速准分析变更媄响方面，q是可以从工具中获得有限的帮助。首先根据需要实施一些媄响分析，然后Ҏ自己或小l其他高U成员评审来判断变更的媄响。你可能需要上面提到的工具对你的判断进行反复确认?/p>
4. 对上q内容的两个忠告 4.1 不要降低代码质量 Z快速交付，所以没有全盘理解架构，但绝不能以降低代码质量ؓ条g。下面是一些你可能因ؓ只考虑快速交付而引发的代码质量问题?/p>
因ؓ修改代码涉及到很多的依赖Q所以新增代码相对而言风险较小。例如，?个用例都调用了某个方法。ؓ了改q某个用例，你需要修改这个方法的实现。最单的做法是复制q个ҎQ重命名Q然后在改进的用例中调用新方法。千万不要这么做。代码冗余绝Ҏ非常有害的。尝试对Ҏq行包装或者重写，甚至是直接修改，然后重新试所有用例，通常停下来想一惻I然后亲手d施，是一个比较好的方式?/p>
另一个例子是?#8220;private”Ҏ改ؓ“public”Q得别的类也可以调用。尽量不要将非必ȝ部分暴露出来。假如ؓ了更好的设计需?span class="wp_keywordlink" style="padding-right: 0px; padding-left: 0px; padding-bottom: 0px; margin: 0px; padding-top: 0px">重构Q就应当着手去做?/p>
大部分应用都有确定的l构和模式来实施。修复或增强E序Ӟ认你没有偏这L模式。若对约定不定Q请其他的高U开发者来审核你的变更。若你必d一些违背约定的实施Q尽量放|于一个规模较的cMQ一?00行代码的cM的私有函数应当不会媄响应用的整体设计Q?/p>
4.2 不要停止深入理解目架构 按照文章列出的方式，假设你能够在寚w目了解较的情况下进行交付ƈ以此持箋下去Q可能你会停止对目架构的深入了解。这样从长远角度来说对你的职业生涯没有帮助。当你的l验增加Ӟ你应当承担比较大的模块Q务。如构徏一个完整的新特性或者修攚w目的一些基设计{较大的改进。当你能够做q些改进Ӟ你对目的整体架构应该相当了解。文中列丄Ҏ是让你在最短的旉内提升自己，而不是阻止你完整理解整个目?/p>
5. l论 整篇文章集中在对目q行必要了解的前提下q行快速交付。你可以在不降低代码质量的前提下q么做?/p>
若修复一个bugQ迅速定位ƈ修复。有必要可以使用q行时分析工兗若新增一个特写，可以L怼特写Q理解流E（有必要用工Pq编写?/p>
或许q些听v来很单，但是实用吗？当然。但前提是你有良好的java技术以及对框架_了解才能先修改代码，然后对变更媄响进行分析。对变更影响的分析比实施变更需要更多的技巧。你可能需要高U开发h员协助你分析变更影响?/p>
大约?0%的IT可操作预用于简单的bug修复和功能增强。根据文中的Q对于维护活动中的经费的节省应当q是很有帮助的?/p>
作?Choudary Kothapalli 也是 MaintainJ 目的徏立者?/p>
英文原文Q?a class="external" style="padding-right: 0px; padding-left: 0px; padding-bottom: 0px; margin: 0px; color: #0b5c77; padding-top: 0px; text-decoration: none" target="_blank">Choudary Kothapalli
转蝲自伯乐在U?nbsp;http://blog.jobbole.com/16526/
]]>
设计模式的书c看q不，从经典的GOF的《设计模式》、《设计模式解析》，到《Java与模式》，再到《Head First Design Pattern》等{?/p>
重构斚w的书看过《重构：改善既有代码的设计》。但是，《重构与模式》这本书的收h大?/p>
《重构与模式》一书，最大的特点是：例子详细Qƈ且都是来源于真实的项目（例如QJunit试框架QHttpParser{）Q而不是那么玩具代码?/p>
׃Junit和HttpParserQ在开发过E中l常用到Q所以，感觉q些例子很亲切，实用价值很大?/p>
该书q有一个特ҎQ每ơ重构过E都是@序渐q的Q每ơ重构都是有章可循的Q重构原则大都来自《重构：改善既有代码的设计》）Q一直到最l的设计模式?/p>
q一q程Q也很好地反映了一点：设计模式是重构的目标Q?br />
看完q本书后Q个为在目的初期设计中不应该过分考虑如何利用设计模式Q设计模式更多时候应该是应用在后期的pȝ重构中，q样可以避免Z模式而模式的q度设计?br />
接下来，我会把这本书的体会，l合实际开发的目应用Q写一些重构和模式相关的文章?/p>
友情提示Q本博文章欢q{载，但请注明出处Q?a href="http://www.aygfsteel.com/hankchen">陈新?/a>