结束语与参考文献

四. 结束语

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

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

原文发布于微信公众号 - 逸言(YiYan_OneWord)

原文发表时间:2014-08-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

扫码关注云+社区