How to Convert a Legacy Site over to Zend Framework - 1 Favour Refactoring over Rewriting
Over the years, I have often been faced with the choice of whether to refactor or rewrite.
In fact, on many occasions I had no idea that i was making the choice. I just thought I was coming up with ‘a new plan’ or way of doing something.
It was the complexity of one of my sites that drove me to look into using a framework. Until then, the whole ‘do not re-invent the wheel’ concept was just wrong. It is much easier/quicker to write your own stuff than learn other people’s ways of doing things.
In some ways this is still correct.
But, nowadays, I am sold on the benefits of using a framework.
One thing that frustrated me for years, whilst learning about Zend Framework (ZF) was the lack of tutorials on how to convert a site to ZF.
The ‘getting started’ tutorials always assumed that you were starting a brand new project.
How many people come to ZF as a newbie with no projects under their belt? How many with no projects in their keep, no projects that they are bound to be caring for?
None, I imagine.
So, why are there so few tutorials about converting to ZF?
Well i think i know the answer.
Because to convert a site to the ZF is like rewriting your site rather than refactoring a site.
So what is wrong with a rewrite?
Nothing , in theory.
But looking back over the years, if i look at all the code that I have rewritten from scratch - I cannot see any that has really successfully been merged with my older code. I laugh, because I can think back to the time when i set off on those paths , thinking . oO(I will just rewrite this little function/class and then ditch the old code when i have converted all the data into the new system.)
(Yes, I use SVN too - but that I see that as more of a refactoring tool than a rewriting tool.)
5 years later and those two strands of code are still chugging along next each other…but on completely different railway tracks. I doubt they will ever meet again.
The best I can hope for is “An anti-corruption layer” (Eric DDD Evans) to wrap up these ‘balls of mud’ and make them chat via specialized communication services.
So, back to that task of converting a legacy site to the ZF.
A framework, by nature, sits underneath an application. I have created a few ZF base-projects with the intention of slipping them under an existing application. And guess what, months later, for each attempt I now have 2 applications - one is the legacy app, that old workhorse that just won’t die and the other is a beautiful, ZF-driven, application that has hardly any features. Each of them chugging along on their own tracks. Never the twain shall meet.
Maybe i will change my mind in a few months - but here some
NOTES TO SELF for future:
1. You cannot slip a new framework underneath your existing application unless you have the ‘model’ of your old application completely carved away from the controller and view.
2. Don’t try to build a new ZF MVC framework in the hope that you can then slip the old model into it - if your old legacy app is widely different from that new framework.
Instead:
Refactor the old application into a shape that mimics the ZF. When you refactor, you need to know where you are heading. Just head for a counterfeit framework. Copy the patterns. Copy the ideas. Copy the terminology. But refactor rather than rewrite.
Eventually you will have an application that is much closer to the framework that you admire.
Then, you get all the benefits of a framework.
* well-documented structure of code, that
* collaborators can step-into, and
* understand quickly (if they have worked with the framework before)
Obviously there is the danger that too similar naming might fool people into believing that your app and the framework are ‘one and the same’. But it is not as dangerous as mixing bounded contexts of a model. We are talking copying of framework concepts here rather than model.
Then one day, little by little, the two can gradually merge. Maybe.
I have faced a horrible legacy mess of a site but I took the time to attack it. Its like facing a zillion-piece-Tetris-jigsaw-puzzle. At first, it can be overwhelming. The thought of refactoring seems daunting. A rewrite seems so much easier. But I have found that, after a period of flux and once you’ve got the hang of it, each time that you move a piece of the puzzle into place, the whole puzzle shrinks! Eventually that mess gets easier and easier to fix up.
So is this re-inventing a wheel?
Maybe, but its a lesser evil than embarking on rewriting your model and ending up with two models to deal with instead.
June 4th, 2010 at 2:46 pm
Hi Johnnie,
nice article about the thoughts a PHP developer has with every new project. We were at this point in early 2009. We managed to refactor our complete CMS / Shop / App Suite to be ZF based. And we invented some kind of “app-paradigm” to reuse apps in different projects. Maybe it is just what you are looking for: http://www.redsparkframework.com. By the way, its open and mostly for free.
I would be interested in feedback if it met your requirements.
Unfortunately it’s still in german, feel free to ask by mail if google translate screws things up ;-)
Best,
Till
September 7th, 2010 at 12:00 pm
I just discovered your post via an article in the German PHP Magazin (http://it-republik.de/php/, printed article, issue 6.10). About RedSpark ^^ :-)
I absolutely share your approach to refactor until the legacy app mimics the new framework driven structure BEFORE eventually merging with ZF.
Two questions:
1. qutoting you: “I have faced a horrible legacy mess of a site but I took the time to attack it.”
On the About Page you mentioned your memory was terrible :-P Can you somehow find out how big (loc) that application was? What kind of an app was it? Did you successfully migrate the whole app to ZF? How long did it take?
2. quote: “(Yes, I use SVN too - but that I see that as more of a refactoring tool than a rewriting tool.)”
How do you relate SVN to rewriting and refactoring? I don’t get that. Can you clarify on which SVN features or general versioning techniques you are using for refactoring legacy code?
I am very much interested in this very specific subject (PHP + Refactoring + ZF) and also building a business on top of the whole idea.
So I’d love to read your thoughts on the two questions. Or send me a mail!
September 8th, 2010 at 5:32 pm
Hi Ulrich,
Thanks for your comment.
Big in Germany eh! I seem to have ‘done a Hasselhoff’.
1. It was about 800,000 lines of code. Not all of it was converted to ZF. Some was concreted over with an anti-corruption layer. Its an ongoing process - but the hard work was spread over about 2 years to turn it from ’shanty town’ to ‘manageable’. (I spent a long time doing wrong things and made every mistake you could imagine - so it was a major learning experience!)
2. The svn comment was to acknowledge the fact that version control techniques (tag, branch, merge) are useful for tying small rewrites back into the fold with continuous integration.
I’m glad to hear that you are building a business on this topic. I think there is a lot PHP code out there needing some love and attention. Its probably due to the ability for anyone, like myself, to make a PHP application with little computer science/programming experience and a dangerous amount of enthusiasm.
September 15th, 2010 at 12:30 pm
Thanks for the reply John.
2 years to turn it into ‘manageable’? Pew.
>dangerous amount of enthusiasm
:))
>(I spent a long time doing wrong things and made every mistake you could imagine - so it was a major learning experience!)
I’d love to read about the biggest lessons you learned. And how you would approch the same problem now. What would you focus on now? Which were the biggest mistakes that should to be avoided and why? Which best practices would you suggest and why?
Are you interested in writing a guest post on my future website about the whole experience? The project’s home will be: http://www.refactorphp.com/. I’ll be presenting material about refactoring php apps, probably including a blog, also with related guest articles.
Please let me know if you are interested. Maybe you would like to revisit the URL occasionally until there is some actual content … which will be hopefully very soon ;-)
September 16th, 2010 at 8:09 pm
Hi Ulrich,
Yes - it took ages. The task was not just about converting a legacy site to ZF. More accurately, it was also a conversion from ‘procedural PHP’ into ‘OOP PHP + Zend Framework’.
I suppose one of the most important things that I have learned is that…I am a ‘computer programmer’.
If you study to become a programmer it is no surprise when you become one.
I *used* programming techniques to add a bit of dynamism to an existing, flat, web site, then a bit more, then a bit more. One day I discovered that this thing that I was doing had a name - ‘programming’.
Then, the next lesson I learned was to ‘keep on learning’ - the more I learned, the more I realised how little I knew.
I learnt so much from books like ‘PHP 5 Objects, Patterns, and Practice - Zandstra’, ‘Design Patterns - GoF’, ‘POEAA, Fowler’, ‘DDD - Evans’.
They were really good at providing answers to many of the problems that I was facing. But, sometimes they opened up many more questions. Often these teachings did not square with my own requirements.
So, the next thing I learned was to have ‘enough strength of my own convictions to challenge the Gospel’.
The POEAA book, for example, is a really useful pattern catalogue for designing ‘Enterprise Applications’. But, an Enterprise Application is not exactly a ‘web site’ as we know of it today. I cannot remember seeing the phrase ‘SEO’ in that book, yet SEO is an important aspect of web design.
There came a point where I was confident that I understood a lot of what the ‘Small-talk-school’ was advocating (with its years of experience in designing desk-top and enterprise applications). But, I had to mix this gospel with my own ‘web scripting’ experience.
If you throw yourself into the MVC pattern, for example, you’d be forgiven for thinking that a web interface was simply a replaceable View of a Model. But, if you take SEO seriously, you have to think of the ‘web imprint’ of your web site as a model in itself. Not just any model. Its a published model, an API that you gave to the World, and the World cares about every change that you make to it. So, in essence if you treat a website like a ‘lonesome desktop app’ and try to squeeze it into one Model , one Controller and one View you’ll end up getting a bit stuck.
anyway….I’m going to cut myself short cos i am starting to write an essay.