结束语与参考文献

四. 结束语

遗留系统的技术栈迁移可能是一个漫长艰苦的过程，它的难度甚至要高于新开发一个系统，这是因为我们常常会挣扎在新旧系统之间，并在不断的妥协、权衡中缓步前行。

它是一个复杂工程，需要参与者了解迁移前后的技术栈知识，掌握或者至少善于分析与理解遗留系统。我们需要审慎地做出技术决策，通过识别迁移过程的风险来驱动整个迁移过程。在决定迁移选择的技术时，要根据这些识别出来的风险对这些候选技术做充分的预研，获得可供参考的度量矩阵。我们还可以引入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