应用程序迁移期间要记住的事项：ColdFusion 到 Spring
这个问题是关于移民项目的。目前遗留应用程序位于 ColdFusion 中，我们希望将其迁移到 Spring 框架。
所以我的主要问题是：
- 在考虑迁移项目时需要记住哪些事情？
- 在考虑从 ColdFusion 迁移到 Spring Framework 时，我需要记住什么具体事项吗？
- ColdFusion 与 Spring 框架相比如何？
- 在开始从 ColdFusion 到 Spring 的迁移项目之前，您会建议我熟悉哪些资源？
我知道有些人可能认为这是一个非常开放式的问题，但这是我的第一个迁移项目，我从来没有任何迁移项目的经验，也没有在这里寻找一些有用的指导。
This question is regarding migration project. Currently the legacy Application is in ColdFusion and we want to migrate it to Spring Framework.
So my main questions are:
- What are the things to keep in mind while considering Migration Project ?
- Are there any specifics things that I need to keep in mind while considering migration from ColdFusion to Spring Framework ?
- How do ColdFusion stack up with Spring Framework ?
- What resources would you recommend to get myself familiar with before starting on Migration Project from ColdFusion to Spring ?
I know some might think that this is very open ended question but this is my first Migration Project and I have never had any experience with Migration Project and what looking for some useful guidance over here.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
移民项目充满危险。
第一个危险是，“这既昂贵又痛苦。让我们重建
一切从头开始，并实现任何新的想法或功能
任何营销人员/经理/程序员都使用结构化方法
等等等等......”这条路会导致厄运，因为
1）它是一个开放式的工作量，
2）没有人真正知道旧系统的作用（最近看过规范？），因此你会结束在新系统上线后重新发现旧系统的内容，会给组织使用新软件完成工作的能力带来极大的痛苦和损害，通常情况下，新系统永远无法赶上旧系统，因此重写就会失败。 。
进行这种迁移的正确方法是：坚持保留功能，并转换现有系统。
这种坚持有其自身的麻烦：组织通常必须做出一些改变
出于在迁移发生期间的生存原因。
为了解决这个问题，您确实需要一个自动迁移工具，以便“无功能更改”规则仅在实际转换期间适用，因此尽可能短。迁移工具的开发人员花一些时间来构建它并彻底测试转换工具是可以的；与此同时，本组织可以通过通常的方法增强遗留系统。当迁移工具准备就绪时......扣动扳机，转换代码，修补问题并测试结果系统的有效性。
一旦系统完成迁移，您就可以考虑彻底重组或重塑，因为您知道基本功能仍然健全。
无论您选择哪种自动迁移工具，您都需要注意它生成的代码在新环境中是可维护的。许多转换器都进行了真正幼稚的一对一转换，而生成的代码最终成为在新栏中进行旧版 foo 编码，或者在幼稚的 COBOL 到 Java 转换后被笑称为“JOBOL”。转换工具必须对于如何映射语言结构非常复杂。 （您可能想阅读 PL/1 到 Java 转换）。
你最大的麻烦可能是“测试”。目前的系统已经完成了功能测试吧？呃，您没有进行任何功能测试吗？您将如何验证新系统是否正确实现了旧系统的功能？
这里正确的答案是根据遗留系统的输入输出行为构建遗留系统的测试，并将这些测试应用于遗留系统和迁移的系统。这是一项繁重的工作，没有人愿意做，更不用说付钱了。这是迁移失败的第二种方式。
最后发生的事情是，管理层严重缺乏资金和时间来完成这项工作。通常与开发团队的谈判是这样的：
注意这里没有对工作进行实际的讨论。
6个月后，就会开始互相指责。经理：“我问过你们，你们说 6 个月……”
你们的处境很艰难。认真准备。坚持让人们真正列出所有问题，并做出可信的估计。如果您是第一次进行迁移，那么您没有良好的基础来进行此类估计；如果该组织是第一次，则没有依据来判断任何估计是否正确。
（全面披露：我有偏见。我构建自动迁移工具已有 22 年了。查看 B2 迁移。）
Migration projects are fraught with danger.
The first danger is, "this is expensive and painful. Lets rebuild
it all from scratch and implement any new idea or feature that
any marketer/manager/programmer has using structured methodologies
and blah blah blah..." This path leads to doom, because
1) its an open-ended amount of work, and
2) nobody actually knows what the old system does (seen the spec recently?) and therefore you'll end up rediscovering what the old system after the new one goes live, at great pain and damage to the organizations' ability to do its job with the new software. Usually in fact the new system never catches up with the old one and so the rewrite dies an ugly death.
The right way to do such a migration is: insist on leaving the functionality alone, and convert the existing system. No new goodies, features, methodologies.
That insistence has its own troubles: the organization often has to make some changes
for survival reasons during the window in which the migration is occurring.
To handle that, you really want an automated migration tool, so that the "no functionality changes" rule only applies during the actual conversion, and is thus as short as possible. Its ok for the developers of the migration tool to take some time to build it and thoroughly test the conversion tool; in the meantime, the organization can enhance the legacy system by its usual methods. When the migration tool is ready.... pull the trigger, convert the code, patch the problems and test the result system for effectiveness.
Once the system has been migrated, then you can consider radical restructuring or reshaping, knowing that the fundamental functionality is still sound.
Whatever you choose for an automated migration tool, you need to be careful that the code it produces is maintainable in the new environment. Many converters to truly naive 1-to-1 conversions, and the resulting code ends up being legacy-foo-coded-in-new-bar, or what is laughingly called "JOBOL" after naive COBOL to Java conversions. The conversion tool must be sophisticated about how it maps the language constructs. (You might want to read this SO discussion of PL/1 To Java Conversion).
Your biggest trouble is likely to be "testing". The current system has complete functional tests, right? Uh, you don't have any functional tests? How will you verify the new system implements what the old one did correctly?
The right answer here is to construct tests of the legacy system in terms of its input-output behavior, and apply those tests to both the legacy system and the migrated one. This is a lot of work, and nobody wants to do it, let alone pay for it. This is the second way migrations fail.
The last thing that happens is that management woefully underfunds and undertimes the work required to do this right. Usually negotiations with the development team go like this:
Notice how there's no actual discussion of the work here.
At the end of 6 months, finger pointing will start. Manager: "I asked you guys, and you said 6 months..."
You're in for a rough ride. Prepare carefully. Insist that people really list all the issues, and that they produce believable estimates. If its your first time doing a migration, you have no good basis to make such estimates; if its the organization's first time, it has no basis by which to judge if any estimate is right.
(Full disclosure: I'm biased. I've been building automated migration tools for 22 years. Check out B2 migration.)
这在很大程度上取决于 CFML 应用程序的现有结构。虽然有一个可用于 CFML 的框架与 Spring 的 IoC 部分非常匹配，但我怀疑您正在考虑从非结构化 CFML 应用程序迁移到 Spring Web，而不仅仅是 IoC 部分 - 并且您正在考虑从一种语言到另一种语言：CFML 到 Java。
所以现实是：这不是一个迁移项目，而是一个彻底的重写。
我知道你说过“迁移是一项要求”（原文如此），但我认为你需要更多地解释一下是什么推动了这一点，这样人们就可以提供比“你疯了，不要这样做！”更好的答案。 - 因为您提供的信息很少，没有人能够提供有用的答案。
至于这种迁移的机制，如果您有一个使用 ColdSpring 的结构良好的 MVC CFML 应用程序，您可以将模型逐段迁移到 Java 并使用 Spring 的 IoC 而不是ColdSpring 用于 bean 管理（您希望 Spring 成为 ColdSpring 的父 bean 工厂，以便 CFML 代码的其余部分仍然可以访问新迁移的 bean）。
将所有模型（和数据访问层）迁移到 Java/Spring 后，您将处理所有 .cfm 视图页面到 .jsp 视图页面的转换，并重写所有 CFML 控制器/侦听器（取决于哪个 CFML框架正在使用）到 Spring Web 处理程序。
这可能是一个庞大的项目 - 假设一个结构良好、由 MVC 框架驱动的 CFML 应用程序已经使用 ColdSpring 来管理模型。
我敢打赌，您一开始就是一个非结构化的混乱（这就是为什么有迁移指令的原因），在这种情况下，您的大型项目只会变得更加庞大。
Much is going to depend on the existing structure of your CFML application. Whilst there is a framework available for CFML that matches the IoC portion of Spring fairly closely, I suspect you're looking at migrating from an unstructured CFML application to Spring Web, rather than just the IoC portion - and you're looking at moving from one language to another: CFML to Java.
So the reality is: it's not a migration project, it's a complete ground-up rewrite.
I know you said "Migration is an requirement" (sic) but I think you need to explain a bit more about what's driving this so folks can provide a better answer than "You're crazy, don't do it!" - because with the little information you've provided, no one is going to be able to provide a useful answer.
As for the mechanics of such a migration, IF you have a well-structured, MVC CFML application that uses ColdSpring, you could migrate the model, piece-by-piece to Java and use Spring's IoC instead of ColdSpring for bean management (you'd want Spring to be the parent bean factory for ColdSpring so that the rest of your CFML code could still access the newly migrated beans).
Once you have all your model (and data access layer) migrated to Java / Spring, you would then tackle the translation of all your .cfm view pages to .jsp view pages and rewrite all of your CFML controllers / listeners (depending on which CFML framework is in use) to Spring Web handlers.
It's likely to be a massive project - and that's assuming a well-structured, MVC-framework-powered CFML application that's already using ColdSpring to manage the model.
I'll bet that what you're starting with is an unstructured mess (which is why there's a directive to migrate) in which case your massive project just got more massive.