将 ColdFusion 5 基于标签的代码重构为 CFC
我觉得有必要将旧的基于 CF5 的代码重构为 CFC 的代码。 我们已经在 ColdSpring 和 Transfer 中有一些代码，但感觉对 ColdSpring 和 Transfer 进行大量重写是没有意义的。
我会遇到哪些技巧、方法和陷阱。
我怎样才能让这变得容易？
我不介意将 ColdSpring 保留在其中，但由于项目的规模，我担心 Transfer。
编辑：我的代码库已经运行了 7-8 年并且非常庞大。 描述它会很困难，但是我正在寻找有关方法的通用建议
I feel the need to refactor my old CF5 based code into CFC's. We already have some code in ColdSpring and Transfer but feel a large rewrite to ColdSpring and Transfer is pointless.
What tips, approaches and gotchas will I hit.
How can I make this easy?
I don't mind keeping ColdSpring in the mix but Transfer is the bit I'm scared of with the size of the project.
edit: my code base has been going for 7-8 years and is vast. To describe it would be difficult, however I'm looking for generic suggestions on approaches
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果只是为了它而改变整个代码库，如果它基本上有效的话，就会给你的系统带来很多潜在的错误。 我认为没有一个简单的方法可以做到这一点。
如果您查看站点的 1：最有可能更改和 2：执行最多的区域，您可能能够定位一些可以从更改中受益的区域，并了解它们如何轻松地融入基于 CFC 的框架，以及有什么好处。 但对于大多数代码来说，如果工作正常，可能没有迫切需要更改。
然而，每当您需要对系统的一部分进行重大更改时，可能值得从面向对象的角度进行查看，并在适用的情况下移动现有代码。
Changing the whole code base just for the sake of it if it basically works would be introducing a lot of potential bugs into your system. I don’t think there is an easy way to do it.
If you look at the areas of your site which are 1: most likely to change and 2: executed the most you may be able to target some areas which could benefit from change and see how easily they would fit into a CFC based framework, and what benefits. But for most of the code if it is working OK, there may be no pressing need to change.
However whenever you need to do a major alteration to part of the system it may be worth looking at that from an OO perspective and moving the existing code over, where applicable.
在我正在进行的一个项目中（几乎相同的情况，甚至更多——大多数代码都非常糟糕），我正在使用一种我称之为“波浪式”的技术。 我使用的一般想法如下：
为什么要“wave”？ 在一个大项目中，我不能只是坐下来重写所有与客户相关的代码。 所以我一步步做到了。 例如，我必须处理客户注册，并用一些属性来扩展它。 我已经创建了基本组件，将方法移至验证表单（检查登录、电子邮件等）并添加客户 - 因此该页面以新样式工作。 晚了我将需要改进发票页面，我需要在其中获取发票所有者详细信息：我只需将方法添加到客户管理器中并摆脱直接查询。 稍后编辑客户页面...也可以称为“按需重构”或smth。
根据您当前的项目状态，可能还有其他内容。 但这对我帮助很大。 希望您会发现这些提示很有用。
In one of my ongoing projects (almost same situation, even more -- most of code is really bad) I am using technique I'd called "wave-style". General ideas I use are following:
Why "wave"? In a big project I can't just sit and rewrite all customer-related code. So I have make it step by step. For example, I have to work on customer signup, extend it with few attributes. I've created basic component, moved there methods to validate form (check login, email etc.) and add customer - so this page works in new style. Lated I will need to improve invoice page, where I need to get invoice owner details: I just add method into customer manager and get rid of direct queries. Later edit customer page... Also it can be called "on demand refactoring" or smth.
There can be additional stuff relying on your current project state. But it helped me a lot. Hope you'll find these tips useful.
在进行任何更改之前：创建一整套回归测试！
重构时，目标必须首先保留功能，这样就不会直接影响客户。
我也同意 Sergii 的波浪式重构——这允许你将事情分解成可管理的块，而不是一次性完成所有事情。
但无论您使用什么方法，您可以创建的回归测试越多越好 - 这实际上是您可以确认您没有无意中更改某些内容的唯一方法。
Before you change anything: create a full set of regression tests!
When refactoring, the goal has to be preserve functionality first, so that you don't directly affect your clients.
I agree with Sergii's wave-style refactoring also - this allows you to break things into manageable chunks rather than doing everything in one go.
But whatever method you have, the more regression tests you can create, the better - it's really the only way you can confirm you haven't unintentionally changed something.
在不了解您的任何代码的情况下，这是极其困难（近乎不可能）回答的。
这个问题有点像“我想拆解我的旧大众汽车并用零件建造一辆新大众汽车，我应该考虑什么？” :-)
This is extremely hard (bordering on impossible) to answer without knowing any of your code.
The question is a bit like "I want to disassemble my old Volkswagen and build a new one from the parts, what should I consider?" :-)
我的建议是首先将您的业务逻辑封装到 CFC 中，而不是担心站点的整个表示层。
只需专注于业务逻辑，您就能够将最重要的功能引入 CFC 并减轻维护噩梦。 将这些 CFC“插入”您现有的站点也不会太难。
在将尽可能多的业务逻辑放入 CFC 中后，您会注意到这个巨大的怪物已经被缩小了尺寸。 此时，您现在可以决定要对站点的表示层执行哪些操作。 现在，您可以从众多可用框架（CFWheels、FuseBox、ColdBox、Mode-Glue）中自由选择，以通过表示层进行移植。
或者你可以直接说“管它呢”，然后从头开始在 CFWheels 中重写整个内容:)
My advice would be to start off by encapsulating your business logic into CFCs instead of worrying about the whole presentation layer of your site.
By just concentrating on the business logic, you'll be able to get the most important functionality into CFCs and ease the maintenance nightmare. It also won't be too hard to just "drop-in" these CFCs into your existing site.
After getting as much business logic into the CFCs as you can, you'll notice that the enormous monster has been cut down to size. At that point you can now decide on what you want to do with the presentation layer of your site. You're now free to pick from a multitude of frameworks available to use (CFWheels, FuseBox, ColdBox, Mode-Glue) to port over the presentation layer.
Or you could just say "the heck with it" and rewrite the whole thing in CFWheels from the start :)
如果您不使用版本控制，请在执行其他操作之前进行设置。 能够从失败的重构中退出是一个重要的救星。 之后我同意所发布的内容。 你会想要一次处理一小部分——分而治之。
If you are not using version control get that set up before you do anything else. Being able to back out of broken refactoring is a serious life saver. After that I agree with what has been posted. You will want to take on small chunks at a time - divide and conquer.