All of the steps we've taken, up to this point, have talked specifically to bringing your code into this century. Chances are, you're still maintaining this application. Maybe you have a new module that marketing wants you to add, or sales needs this other sub-app rewritten to catch up with the times. You aren't really going to do this in Fusebox 3 again?
Let's stop a minute and talk about new code. Most applications who live this long rarely stop growing. They generally started off as prototyping a "neat idea", and became thousands of templates of code serving multiple purposes. Most of these also fell into the Big Ball of Mud Design Pattern, which is probably part of why you ended up here in the first place. Things are starting to fall off.
First of all, make yourself a promise to do any work, going forward, in a manner that benefits both your business, your clients, and your future development staff, without cutting corners. If you aren't going to do it right the first time, when do you think you'll get the opportunity to fix it? Getting to market a month later will cost you far less than pushing early with bugs, poor performance, and missed expectations.
Second, consider a modern framework. I know, some people hate frameworks, but the advantage is a consistent way of doing things that is already documented. I've used Fusebox, Mach II, ModelGlue, ColdSpring and ColdBox, but overall I prefer FW/1 and DI/1. They are lightweight, their flow seems like a natural extension of ColdFusion's existing application framework, and they work well with large, high traffic systems (in my experience). Whatever your preference may be (or become), go with something that enforces a Model View Controller architecture, for a separation of concerns and easier overall maintenance. Choose the ones that are right for your apps, stick with them, and make them your standard for new development moving forward.
Third, come up with a process. Document your development process, and stick to it. From requirements gathering, to R & D, to source control strategies, to client sign-offs and end-user testing, put together a complete end-to-end methodology for how you vet tasks, write code, test work, and promote projects from local to staging to prod. Eliminate the guesswork, by defining a standard. If the process breaks down, or something just isn't working, then discuss, adjust, and move forward.
The last thing I will say on this is "plan". Take the time to sit down and write it all out. Gather all of your requirements, draw up some mockups of interfaces and detailed diagrams of interactions, and break everything down into small, measurable, digestible sub-tasks. Setup a system like Redmine to help you track assignments and progress, integrating them with your source control system wherever possible.
In our next post we'll get back to the business of upgrading our Legacy Code, to make faster and more responsive applications.
This article is the fifteenth in a series of articles on bringing life back to your legacy ColdFusion applications. Follow along in the Legacy Code category.