Everyone has some form of Legacy code, and at my new job we have plenty of it. The Deseret News has been around in paper format since 1850, and has had a web presence since 1996. I can still find parts of our codebase for running with Sybase and Vignette. Fortunately, most of the code we work with is much more modern using the latest PHP with an in-house MVC framework. However, there is still one big piece written in a less than ideal system. Its still PHP, but much more hacked together. It is our backend CMS system for controlling the website. It is painful to use, and we get many complaints all the time about it. When I joined the company three months ago, I was told we were going to completely rewrite it. Three months later, the “rewrite” of the CMS is still ages away and we’re continuing to hack to support requested changes.
So I started to put together some plans for the colossal undertaking of re-writing our CMS. The more I looked, the more I realized just how much “stuff” this thing did. There were lots of complex things that we didn’t support anymore, but also complex tools we used on an hourly basis. It would take months before we would be able to replace even the basic core functionality.
Then, on Twitter, I saw a link for a talk Paul M. Jones gave at the Nashville PHP Usergroup. It was entitled: “It Was Like That When I Got Here: Steps Toward Modernizing a Legacy Codebase.” I couldn’t think of a better title for that talk, nor a better talk to listen to at this very moment. It was a light bulb going off saying “Hey, maybe we should take a second look at just fixing up our existing CMS.” If you haven’t watched his talk yet, you need to, it is definitely worth it.
To be honest, the code Paul showed in his slides were 10 times worse than what we have to deal with. The only real reason our old CMS is in it’s current state was the idea of “Hey, we’ll be making a new CMS soon, so we’ll just hack together the bare minimum on this old thing.” So we sat down and had a serious conversation with out team on “Why not just refactor?” Yes, there will be a lot of work and pain involved, but it offered one huge upside: we could iterate and achieve gains right now.
So we’re doing a quick audit of things that are in there we don’t support anymore, and there is a lot. All of that will be removed. Then we’re going to have a list of all the existing functionality and give it to the people who actually use it and have them tell us two things. On a scale of 1 to 10, how painful is this feature to use right now, and then have them prioritize which features they’d like to see fixed first.
As a development team, we’re listing out all the pain-points of developing with the old system. We’re doing the same thing with our list and adding one more datapoint: how difficult to make the change? What will it take to upgrade the old templating system? Can we implement our new framework and have it fall back?
Using these lists to decide what to refactor, we can get the biggest gains for the least amount of work. If we were to rebuild, we would get the smallest gains (if any) of barely having something functional with the greatest effort.
So over the next few months we’ll be refactoring our old CMS, and while it’ll be painful, it will give us a much better end result.
Related Posts
- Characteristics of Good PHP Code At the time I am sitting in the Las Vegas airport waiting for a very delayed layover flight to San Diego. Wonderful weather causing all sorts of headaches. So I’ve decided to make the best of my time by writing the introductory article to a series of PHP articles. I’ve...
- ASP .NET GridView Access to Data In Code There are situations where you want to gain access to the GridView’s DataSet to display extra information outside of the GridView. I found the following code to work the best for me. You can get the information from the DataSource of a GridView by doing the following: DataView dv =...
- Working with Middle-Scale Websites I’ve been thinking about this idea for awhile, and I thought I would put a name to the thought. I brought up this idea while I was giving my “Real Life Scaling” presentation at the Utah Open Source Conference in 2009. Here is the problem I think most individuals in...
But those Vignette URLs were so awesome
One is happy to be of service.
One thing I’ve had a lot of luck with is redoing sites using the Kohana framework. You can just stick the current site in the html root directory, rename Kohana’s front controller from “index.php” to something unique, and pass through all unknown controllers through to the old site directly.
Then you just rewrite a section at a time to link to the new stuff, with the option of just disabling that new controller if there’s a serious problem and having it fall back entirely to the old code.
I’ve only done it with small-to-moderate sites before though. I can’t speak for how effective that would be to a Very Large Site Indeed.
[...] PHP PHP Master | The Importance of Code Review PHP Master | Fresh thinking for PHP developers. Learn PHP and MySQL – Tutorials. Master PHP Script, Date, PHP Contact Form and Validation, SOAP and much more Refactoring or Rebuilding: Working with Legacy Code | Justin Carmony [...]