四. 结束语
遗留系统的技术栈迁移可能是一个漫长艰苦的过程,它的难度甚至要高于新开发一个系统,这是因为我们常常会挣扎在新旧系统之间,并在不断的妥协、权衡中缓步前行。
它是一个复杂工程,需要参与者了解迁移前后的技术栈知识,掌握或者至少善于分析与理解遗留系统。我们需要审慎地做出技术决策,通过识别迁移过程的风险来驱动整个迁移过程。在决定迁移选择的技术时,要根据这些识别出来的风险对这些候选技术做充分的预研,获得可供参考的度量矩阵。我们还可以引入BDD框架来编写可运行的功能场景,以此来寻找失去的知识,同时兼得验收测试的保护网。
我们可以通过引入持续集成,建立快速反馈环,以避免迁移时做出的改动对原有系统造成破坏。同时,还必须具备技术迁移的能力。我们可以考虑引入一些最佳实践或迁移方法,例如抽象分支、影响结构图、特征草图,运用设计模式和重构手法来改善遗留代码,以利于技术的迁移。当然,团队协作、架构设计、组织管理、进度跟踪等一系列技术与管理实践同样重要,只是这些实践并非技术栈迁移所必须的,而是所有开发过程都必须经历的过程,因而本文不再赘述这些内容。
参考文献:
[1]:http://en.wikipedia.org/wiki/Legacy_system,原文为:“A legacy system is an old method, technology, computer system, or application program.”
[2]:文章How Rackspace Now Uses MapReduce And Hadoop To Query Terabytes Of Data
[3]:烟囱系统,一种反模式,http://sourcemaking.com/antipatterns/stovepipe-system。
[4]:供应商锁定,一种反模式,参见http://sourcemaking.com/antipatterns/vendor-lock-in。
[5]:Gorge Fairbanks:Just Enough Software Architecture,参见第3章Risk Driven Model
[6]:以上所述皆为BDD框架或整体工具。
[7]:Jez Humble:Make Large Scale Changes Incrementally with Branch By Abstraction
[8]:Michael Feathers:Working Effectively with Legacy Code