Refactoring cf5 tag based code into CFC's

Question

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

Answer 1

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?" :-)

Answer 2

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:

1. Splitting processing from output. I can not implement true MVC here, but at least I can move view into separate templates (sometimes re-use them) and prepare all data in basic (model) templates.
2. Move all repeating code into components -- this is one of most important tips.
3. Group related functions into components. Say, all customer-related info grouped into CustomerManager.cfc, invoices into InvoiceManager.cfc etc.

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.

Answer 3

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.

Answer 4

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 :)

Answer 5

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.

Answer 6

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.