标签：java coldfusion migration spring

这个问题与移民项目有关.目前,遗留应用程序位于ColdFusion中,我们希望将其迁移到Spring Framework.

所以我的主要问题是：

>在考虑迁移项目时要记住哪些事项？
>在考虑从ColdFusion迁移到Spring Framework时,是否需要记住任何细节？
> ColdFusion如何与Spring Framework叠加？
>在开始从ColdFusion到Spring的迁移项目之前,您会建议您熟悉哪些资源？

我知道有些人可能认为这是一个非常开放的问题,但这是我的第一个迁移项目,我从未有过任何迁移项目的经验,以及在这里寻找一些有用的指导.

解决方法:

移民项目充满了危险.

第一个危险是,“这是昂贵和痛苦的.让我们重建
从头开始,实现任何新的想法或功能
任何营销人员/经理/程序员都使用结构化方法
而且等等等等……“这条道路导致厄运,因为

1)它是一个开放式的工作量,和

2)没有人真正知道旧系统做了什么(最近看过规范？)因此你最终会重新发现旧系统上线后的旧系统,给组织的工作能力造成极大的痛苦和损害使用新软件.通常情况下,新系统通常不会赶上旧系统,因此重写会导致丑陋的死亡.

执行此类迁移的正确方法是：坚持单独保留功能,并转换现有系统.没有新的好东西,功能,方法.

这种坚持有其自身的麻烦：组织经常需要做出一些改变
出于迁移发生的窗口期间的生存原因.

为了解决这个问题,您确实需要一个自动迁移工具,因此“无功能更改”规则仅适用于实际转换期间,因此尽可能短.移植工具的开发人员可以花一些时间来构建它并彻底测试转换工具;与此同时,组织可以通过常规方法增强遗留系统.当迁移工具准备就绪时……拉动触发器,转换代码,修补问题并测试结果系统的有效性.

一旦系统迁移完毕,您就可以考虑彻底重组或重塑,因为我们知道基本功能仍然是合理的.

无论您选择何种自动迁移工具,都需要注意它所生成的代码在新环境中是可维护的.许多转换器实现了真正天真的1对1转换,并且生成的代码最终成为旧式的foo编码的新条形码,或者在天真的COBOL转换为Java之后笑称为“JOBOL”.关于如何映射语言结构的转换工具必须很复杂. (你可能想阅读这篇关于PL/1 To Java Conversion的SO讨论).

你最大的麻烦可能是“测试”.目前的系统有完整的功能测试,对吧？呃,你没有任何功能测试？您将如何验证新系统是否实现了旧系统正确执行的操作？

这里正确的答案是根据输入输出行为构建遗留系统的测试,并将这些测试应用于遗留系统和迁移系统.这是很多工作,没有人愿意这样做,更不用说为此付出代价了.这是迁移失败的第二种方式.

最后发生的事情是管理层严重缺乏资金并承担正确执行此项工作所需的工作.通常与开发团队的谈判如下：

Mgr:  How long to do this?
Team:  Two years...?
Mgr:  BZZZT!  Wrong answer, try again...
Team:  One year?
Mgr:  BZZT! ..
Team: (Gulping) 6 months?
Mgr:  OK, get started.

请注意这里的工作没有实际讨论.

在6个月结束时,将开始指点.经理：“我问你们,你说6个月……”

你正在艰难地骑行.仔细准备.坚持认为人们确实列出了所有问题,并且他们产生了可信的估计.如果您是第一次进行迁移,那么您没有良好的基础来进行此类估算;如果该组织是第一次,它没有依据判断任何估计是否正确.

(完全披露：我有偏见.我已经建立了22年的自动迁移工具.请查看B2 migration.)

标签：java,coldfusion,migration,spring
来源： https://codeday.me/bug/20190717/1484451.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。