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

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!

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.

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

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.