In Re-Factoring CFML Applications, Part 1, I gave some background about the development of old applications and how over time they degrade and become difficult to maintain and extend, and then I laid out some reasons for re-factoring versus re-writing from scratch, and I provided some background on the development of application frameworks and how they have helped standardize software development over time. In Part 2, I will give you a sample plan for how you can approach a re-factoring project. In part 3, I will go into some details about what that re-factoring looks like when moving a CFML application into FW/1.

Sizing Your Project

Project managers start with a plan, a roadmap for how to achieve the objectives of the project, and that is where we will start. First, you need to have a sense of the size of the project. Here are some questions you can ask as you try to assess the potential size of the project:

• How many lines of code does the current project contain?

This question by itself isn’t that good of a gauge of the size of a project, but it can help you make a very broad estimate about scale and scope. A project with 20K lines of code (LOC) is very different in size than a project with 200K LOC. While it isn’t a very accurate indicator of size, KLOC can give you a quick way to do a first pass assessment at the size of the project.

• How many distinct views/screens are there in the application?

Each view/screen has a corresponding view (and potentially one of more controller actions) in FW/1. It can be harder to get an answer to this number than it is to answer the KLOC question, but it will help you make a more accurate assessment about the size of the re-factoring project since this number translates directly into code that you need to write.

• How many entities are there in your database/persistence layer?

The answer to this question affects how complex your data model will be and could make a big difference in the amount of effort involved in converting it to FW/1.

• Do you currently use ORM or do you plan on using ORM in your re-factored application?

Object relational management (ORM) provides logical mapping from objects in your code to the persistence layer in your application and handles the nitty gritty of moving data in and out of it. If you already use ORM, you are probably going to continue to use ORM because you have already invested the time in setting up the application objects and mapping them to the persistence layer. ORM is a black box and my general preference is not to use it because it forces you, in my opinion, to surrender too much control over a critical part of your application, but it has its place. The upside of ORM is that it can save you a significant amount of effort over managing the persistence layer interactions yourself. Once you have set up the object definitions in code, the ORM system will handle getting data to and from your persistence layer. The downside is that you will have little control over how those interactions work and a limited ability to optimize those interactions compared to managing them directly in code.

• Is your application broken into separate and distinct areas that would do well to treat as individual applications?

FW/1 has the ability to treat separate parts of an application as separate applications while maintaining a single logical root. Whether you choose to use modules in FW/1 or not is a question you have to answer, but suffice it to say that small applications (under 50K LOC) should not in general need modules, and even larger applications may not need modules depending on how they are logically structured.

Depending on the answers to these questions, you may decide to tackle the entire project in one go, or you may decide to break up re-factoring into multiple projects to limit the size and risk involved in each step of re-factoring. Yes, re-factoring is significantly less risky than re-writing from scratch, but it still involves pulling apart your application and stitching it back together again, so think about size and risk before you commit to more than you can handle in one go.

Creating A Roadmap

Next, you will need to build your plan. Have you sized and scoped your project? Do you have a good grasp on available resources and potential funding for external contract work to help you achieve your goals? Have you established a set of baseline expectations for success with the application owners and stakeholders? If so, you have the beginnings of a plan. From there, you can break down your plan into a set of steps needed to actually start writing code.

There are a few big areas that you need to address in re-factoring. That’s a good place to start with your roadmap. You don’t need to actually do all this work for your roadmap, but you should know enough to have a general idea of how long each step will take to accomplish.

• Mapping your views

First you counted the views in your application, now you need to map them to corresponding views in your new FW/1 application.

• Designing your data model

Whether you decided to use ORM or not, you will need to create a data model to interact with your persistence layer. If you already use ORM and plan on carrying it over to the FW/1 application, you might simply be able to migrate your entity definitions from your existing application and be done with it. More than likely, though, your old codebase is riddled with inline SQL queries, including a significant amount of copy pasta that results in hard to maintain code. Mapping how to migrate all that old code into a new data model is an important step in consolidating and streamlining your codebase.

• Mapping application logic

In general, old codebases do not have well-mapped application logic, and like the data model work, this step might take some time once you get into coding. For now, you can use the number of views as a rough estimate for the number of controller methods in your application, and that will give you some idea of how much logic you will need to port over.

• Mapping ancillary services

Things like reports, charts, and PDF generation may need some work to get into FW/1, so make sure you account for them in your roadmap.

• Testing

There are lots of kinds of testing you can undertake, and maybe you already use a test framework for your code. Either way, I encourage you to employ at least basic unit testing using a proper testing framework. I think TestBox is the most current and mature testing framework, it is worth checking out. If you plan on using Behavior Driven Development (BDD), you absolutely need a tool like that. At minimum, provide some estimate of the time required to properly test your code.

In Summary

Above I have laid out a very high level roadmap for you to use when planning a re-factoring project for a CFML application. It is worth noting that a lot of these steps are going to be similar whether you choose to re-factoring your application into a new framework in CFML, or whether you choose to re-write from scratch in a new language.

In part 3 of this series, I will get into the specifics of how FW/1 applications are structured and how you can efficiently port your existing CFML application into FW/1. I might just add a part 4 where I discuss what a project might look like if you opt to port your application to a new language/platform like NodeJS.