最近一个同事要离职,而我刚到新公司没多久,需要从他手里接过原来的系统,经过这些天的交接,确实是难。找到三篇文章,应该帮助很大,
第一篇属于方法论(张逸老师),为我们处理遗留系统制定大目标和策略:
http://www.cnblogs.com/wayfarer/archive/2011/10/09/2203651.html
第二篇属于工具类,介绍了处理java遗留系统有哪些工具:
http://tieba.baidu.com/p/1331700739
第三篇是从工程角度来分析该如何处理遗留系统:
http://www.infoq.com/cn/articles/Dealing-with-legacy-code
第四篇文章则是张逸老师碰到的一个案例:
http://www.cnblogs.com/wayfarer/archive/2011/02/18/1957530.html
下面的文章是摘自第一篇文章,加粗部分是我认为的重点:
处理遗留系统,几乎是每个程序员都不可能绕过的一件麻烦事儿。因为时间压力,技能不足以及功能复杂等诸多原因,常常使得遗留系统的代码变得糟糕混乱,可读性与维护性差,无法保证功能的可测试性,纠缠不清的代码让类、方法之间紧紧耦合在一起。如果遗留系统能够正常工作,那么我们还可以置之不理,即使代码接近腐烂的边缘,我们还可以得过且过。倘若我们需要维护遗留系统,或者需要为它添加新的功能,又或者需要将新的系统与遗留系统进行集成,就必须正视遗留系统带来的问题了。
处理遗留系统,首先需要分析和了解遗留系统,尤其这个遗留系统并非你开发时,更需如此。我们可以考虑双管齐下的办法。一是从业务逻辑方面去了解。相比新系统而言,遗留系统的唯一好处就是它往往是可以运行可以使用的。因此,最好的办法是直接运行遗留系统,通过实际操作了解系统的各个功能点、业务流程。这样的直观感受可以最快地帮助你了解该系统:它能够做什么?它能达成什么目标?它的范围是什么?它存在什么问题?其二则需要从系统架构出发,了解遗留系统的逻辑结构和物理分布。可以阅读架构文档和源代码,如果能够咨询遗留系统的设计者或开发人员,就更好。尽快地描绘出遗留系统的轮廓图,可以帮助你从技术的宏观角度剖析遗留系统的结构与组成。再结合你对该系统业务的理解,快速地掌握遗留系统。如果需要阅读源代码,最好能够从主程序入口开始,找到一些主要的模块,了解其大体的设计方式与编码习惯。由于之前对系统架构已有了解,阅读代码时,不应在一开始就去理解代码实现的细节,而应结合架构文档,比对代码实现是否与文档的描述一致,并充分利用自己的技术与经验,找到阅读代码的终南捷径。例如,如果我们知道该系统采用了MVC架构,就可以很容易地根据Url找到对应的Controller对象,并在该对象中寻找业务功能实现的脉络。又例如我们知道系统采用了SSH框架,而我们又非常熟悉SSH框架,就可以基本忽略系统基础设施的部分,直接了解系统的业务实现。如果是Swing系统,而且在界面中混杂了大量的业务逻辑和界面逻辑,则需要找到系统实现的特点,譬如系统的业务都是通过菜单项进行操作,就可以在界面中找到相关的菜单对象,然后根据这些对象的Action操作,一步一步跟踪。甚至可以利用调试的方法,设置断点,来摸清楚系统的运行机制与执行顺序。
分析遗留系统需要有的放矢,根据目标快速锁定范围。例如,如果我们是因为系统性能出现问题,而要去分析遗留系统,就无需过于关心业务逻辑,而应从性能分析入手。考虑数据库的访问,IO操作,缓存机制,资源的使用等诸多方面。这就需要借助一些经验和技术了,当然也可以考虑使用一些工具,用以诊断性能瓶颈。我们曾经在一个项目中,发现遗留系统的性能问题非常严重。根据分析,我们发现系统对字符串的处理存在问题,大量使用了String类型的对象完成字符的拼接。而在进行数据库查询时,很多代码是直接性地一次将相关表的数据“拉”到内存的集合对象中,然后利用过滤器在集合对象中进行筛选。而在对数据进行更改时,又没有很好地利用业务特性,完成一次提交,导致产生多次数据库访问。在系统的某些公共模块中,重复多次加载了Spring的配置文件。还有某些占用了较大资源的对象,对于系统用户而言应该是同一个对象,但却没有设计为单例。因为我们抱着改善遗留系统性能的目的,所以在分析遗留系统时,就应该事先确定可能导致性能损耗的地方,而不是全方位地去了解整个系统。
在维护遗留系统时,需要根据不同的场景做出不同的决策。简言之,我们需要排定优先级。如果时间紧迫,则解决问题是第一要务。尽快通过出错情况和记录日志辨别出错原因,定位出错代码,并解决之,而不是去考虑设计的优雅,代码的重用。我在一次解决报表显示的问题时,采用的就是这种做法。虽然与错误相关的代码相当丑陋,但由于时间紧迫,解决Bug才是最要紧的,所以我基本上没有去修改或改善既有代码的结构,仅仅解决了问题就结束了对遗留系统的处理。这个问题的处理过程在我的另一篇博客《精益求精,抑或得过且过》中详细论述。是的,我在此时选择了得过且过的做法,主要原因就在于优先级列表中,问题的解决才是最高优先级。在这次处理过程中,我部分地利用了copy & paste的做法,并通过引入新方法的方式来解决bug,而不是直接修改出现问题的方法。这是因为该方法的引用点存在多处,由于遗留系统并没有单元测试的保护,我不能草率地修改,否则可能导致一个bug的修复,结果引入更多无法预测的Bug。
这样的处理方式其实是我不甘心的选择。在时间允许的情况下,我会考虑对相关代码进行一些小的重构,例如提取方法或提取类等。虽然这些重构不能改变遗留系统的本质,但至少可以提高代码的可读性,并能在一定程度下去除代码重复。
这一实例实际引出了单元测试的必要性。如果我们的开发都能够在单元测试的呵护下进行,即使当它随着时间的推移,慢慢变成了丑陋的遗留代码,因为有单元测试的保护,在对它进行手术时,成功的几率却会变得更大。因此,认为编写单元测试是浪费时间的观点,事实上是一种短视的做法。缺乏单元测试,就是一种技术债(technical debt)。现在欠下的,将来总是要还的。我们不能忽略软件的维护成本。事实上,在软件成本中,维护成本所占的比例远远大于开发成本。Kent Beck在《实现模式(Implementation Patterns)》一书中认为:“维护的代价很大,这是因为理解现有代码需要花费时间,而且容易出错。知道了需要修改什么以后,做出改动就变得轻而易举了。掌握现在的代码做了哪些事情是最需要花费人力物力的部分,改动之后,还要进行测试和部署。”
当然,在处理遗留系统时,仍然可以进行单元测试。但它需要的技能更高,付出的精力更多。若要完成对遗留系统的单元测试,首要必须解决的就是依赖。解除依赖是面向对象系统开发中似乎亘古不变的话题。无论你翻阅哪一本面向对象著作,都会提到这个问题。依赖的起源其实在于对象的协作。根据单一职责原则,一个类显然不能承担太多的职责。如果一个系统的所有功能都是一个对象完成的,那么这个对象就成了邪恶的“上帝”对象。它的粒度太大,因此难以重用,不够灵活,细节纠缠,无法维护。这样的设计是我们必须避免的。既然一个类不能承担太多职责,系统要完成客户要求的所有功能,就必须让许多对象互相协作,就像人类社会的人际交往一般,于是,就产生了对象之间的依赖。凡事有利必有弊,这种细粒度的对象协作,虽然保证了对象的重用性、灵活性,却也因为协作带来的依赖,导致对象之间存在一定的耦合度,变得难以替换。由于一个对象依赖另一个对象,就使得我们在单元测试时,无法独立地测试我们的目标对象。
依赖虽然不可避免,但如果能够保证对象之间的良好协作,就能够最大程度保证系统的松耦合。对象协作一般可以分为类协作、接口协作与回调协作(回调协作通常可以看做是接口协作的一种特殊方式,关于这三种协作的特点与方式,我会在以后的文章中谈到)。依赖最弱的是接口协作,这也是我们努力达到的目标,它符合“面向接口设计”的基本原则。同时,也能够保证对象的封装性,通过将实现细节隐藏起来,从而降低对象之间的依赖程度。
知易行难,要对付遗留系统中的依赖问题,通常需要付出百倍的努力。Michael Feathers在其大作《修改代码的艺术(Working Effectively with Legacy Code)》中,给出了很多好的解除遗留代码依赖的实践。例如他提出的接缝类型,隐藏依赖,以及影响结构图。解除依赖需要合理地利用封装与抽象,包括对方法参数的封装与抽象。对于遗留系统而言,Feathers提出的影响结构图尤其有用。当你需要修改某个方法时,影响结构图可以帮助你分析该方法的依赖传播途径,避免因为修改对其他代码造成影响。具体做法可以参考该书。当然,现在有很多IDE工具事实上还支持生成依赖图,它可以在一定程度上帮助你寻找依赖的方向与结构。不过,手工方式的分析尤其是通过手绘影响结构图仍然不可缺少,它更能帮助你深入地理解遗留系统。为遗留系统绘制包图(Package Diagram)同样非常重要,它既能帮助你理解遗留系统的结构,又能为我们找到系统中可能存在的双向依赖和循环依赖,找到分解不合理的包,这就为我们的系统重构奠定了良好的基础。
如果遗留系统非常复杂,以至于无法重构,同时我们又需要在遗留系统的基础上增加新的特性和功能,好的做法就是做好新、旧功能之间的隔离。暂时可以不去考虑遗留系统的原有结构和代码(大多数情况,这些遗留系统其实是可以正常工作的),而只需要为新增的功能做好单元测试,并以好的设计原则与编码规范来要求新功能的实现。同时,我们还可以编写一些自动化的回归测试用例(例如使用Cucumber结合Watir为Web系统编写回归测试),保证新增的功能不会影响到原有系统。如果新增功能的实现需要调用原有系统中的某些类或方法,而这些类和方法却又难以分解,则可以考虑参照原有实现编写新的类或方法,新的类一定要做到合理的封装与抽象,保证它的高内聚与松耦合;也可以在新的类中不去真正实现,而是通过运用Adapter模式来重用旧有的类。
只要不是更改开发平台,通常情况下,我们不会考虑重写遗留系统。如果需要重构遗留系统,就必须采取“分而治之,小步前进”的策略。可以首先选择实现较为容易,或者独立性较好的模块进行重构。将遗留系统逐步提取为一些可重用的模块与类,就可以形成“星星之火,可以燎原”的态势。其中,对于原有类或模块的调用方,由于在重构时可能会更改接口,因此可以考虑引入Facade模式或Adapter模式,或者对接口进行另一层的包装,或者对接口进行适配,使系统慢慢被替换,最后演化为一个结构合理的良好系统。在重构时,甚至可以考虑将一些独立性很好的功能,提取为单独进程下的应用或服务,通过Web Service、Socket或Restful的方式进行调用,既保证了重用,又能够使遗留系统变得更简单,成功瘦身。
我们还需谨记的一点是,虽然模块乃至服务的重构对系统的改造更加重要,但我们却不能忽视代码的质量。小到方法的提取,以及变量的命名都非常重要。也许它不会给系统带来根本的改变,但它却能够改善代码的可阅读性,进而提高系统的可维护性。所谓”聚沙成塔“,无论是系统还是模块,其实都是这些类和方法以及变量组成的。
对遗留系统的处理不可能“一蹴而就”,必须遵循循序渐进的做法,逐步改善。处理遗留系统影响深远,成本也非常高,所以我们也不能因为脑袋一发热,就开始气势汹涌地“提枪上阵”,错将风车当做了魔鬼,结果撞得头破血流。必须对整个遗留系统进行审慎的分析,并结合具体情况考虑这项工程的复杂度、成本与预算,了解团队的重构与设计能力。处理遗留系统的前路漫漫,我们固然需要上下而求索的决心与勇气,却也不能在茫然失措中迷失了前进的方向。遗留系统的处理,必须慎之,慎之,再慎之!