Page 1 of 4
spaghetti to mvc
Posted: Tue Nov 11, 2008 5:47 pm
by freddy13
Hi all,
I have this phpBB based code base. It started of as phpBB installation, and over years other developers contributed to this codebase building more-less same quality code as is the code in phpBB. And this codebase sucks. It is very hard to maintain it, not to mention extending it.
I ended up as main developer here and now I am faced with a challenge: To kill or not to kill!
I don't really know if it's smart to try and produce MVC application out of it. The idea here is to create (or use some OS MVC Frameworks) to gradually 'translate' this code functionality to standards-based MVC application with modularity, tests and everything a proper codebase should have. The problem is there is a large database in behind and fairly great number of users behind this app. I read some text on how to try and do this, but AFAIK nobody has any proves

that this can be done (inside normal amount of resources).
The second options (and the last as far as i can see) is to just drop this codemash, build a new app, transfer (transform) data to this new database architecture created on current and future needs of the app.
Does anyone has any suggestions? I would really appreciate any... Thanks a lot!
Re: spaghetti to mvc
Posted: Tue Nov 11, 2008 8:20 pm
by allspiritseve
Re: spaghetti to mvc
Posted: Wed Nov 12, 2008 12:04 am
by Christopher
I have found that this process in not that difficult -- just tedious. I usually implement a Front Controller and then start moving functionality piece by piece from the separate PHP script Page Controllers into Action Controllers inside a separate application directory. Writing tests along the way documents the current functionality and guarantees that the new URLs do the same thing.
I have done this several times and know it works -- and that it is not much fun...
Re: spaghetti to mvc
Posted: Wed Nov 12, 2008 4:07 am
by alex.barylski
I don't think it matters which approach you take in refactoring...whether you start with controllers or the model/view whatever...
Personally I try and keep things simple so testing is easier...it's about the only time I do unit test cause *everything* breaks.
Off Topic: I was thinking today how ironic it is that Windows was the name Bill selected for a OS as fragile as Windows.
Anyways. I can personally see converting a massive switch statement into controllers as being difficult to unit test as you would likely still have all that model/business/presentation/view logic inside monster controllers. Which is why I start with removing any SQL and forming something of a crude table data gateway, easily testable.
Actually thats a lie...the first thing I do is put all HTML into templates and make sure everything has htmlentities() called on it.
Re: spaghetti to mvc
Posted: Wed Nov 12, 2008 10:10 am
by Jenk
Strangler pattern
Try to isolate a small pieces of functionality, then build new (clean) code around it until you are able to pull out the old code completely.
Re: spaghetti to mvc
Posted: Wed Nov 12, 2008 11:08 am
by alex.barylski
Is that actually a pattern? Haha.
That is the idea in any refactoring isn't it? All problems are best conquered one step at a time and not trying to leap down entire flights of stairs. Thats how you break your ankle.
Sorry for bad joke or whatever it was...I haven't slept yet...I'm so wound up on caffiene it's crazy...

Re: spaghetti to mvc
Posted: Wed Nov 12, 2008 6:04 pm
by freddy13
thanks for your thoughts...
well, i've been thinking that the road must be taken one step at a time... let's say i use Zend Framework...
I extend ZF's front controller/router to route all requests to old code (there is mod_rewrite now in place), and then isolate Table Gateways (models) for every database table now existing.
After design needed controllers and pull out the functionality from current code into these controllers as needed...
After I get all this done, the performance tuning and another wave of refactoring in the OO way...
I think these are all needed basic steps...(writing unit tests along the way).
Am i forgetting anything?
Re: spaghetti to mvc
Posted: Wed Nov 12, 2008 9:47 pm
by josh
Separating the presentation
Re: spaghetti to mvc
Posted: Wed Nov 12, 2008 11:34 pm
by alex.barylski
Mmmmm spaghetti

Re: spaghetti to mvc
Posted: Wed Nov 12, 2008 11:42 pm
by josh
Lasagna > Spaghetti, due to layering

Re: spaghetti to mvc
Posted: Thu Nov 13, 2008 5:39 am
by Jenk
PCSpectra wrote:Is that actually a pattern? Haha.
It certainly is.
I think it was Martin Fowler who first coined the phrase. He was on vacation and sat outside a bar/cafe, looking at some trees which had Strangling Ivy growing on it. This ivy uses the tree (which represents the legacy code) to hold itself in place, until the ivy (of which each shoot represents the small pieces of new code) eventually suffocates the tree and is strong enough to hold itself up, then the dead tree just rots away.

Re: spaghetti to mvc
Posted: Thu Nov 13, 2008 7:42 am
by freddy13
Jenk wrote:Strangler pattern
Try to isolate a small pieces of functionality, then build new (clean) code around it until you are able to pull out the old code completely.
Thanks!
I read this article and it contains some interesting points...
Re: spaghetti to mvc
Posted: Thu Nov 13, 2008 12:06 pm
by Christopher
Jenk wrote:I think it was Martin Fowler who first coined the phrase. He was on vacation and sat outside a bar/cafe, looking at some trees which had Strangling Ivy growing on it. This ivy uses the tree (which represents the legacy code) to hold itself in place, until the ivy (of which each shoot represents the small pieces of new code) eventually suffocates the tree and is strong enough to hold itself up, then the dead tree just rots away.

As ever Jenk, thank you for the great information. Here are a couple of links if people want to read about the pattern:
http://www.martinfowler.com/bliki/Stran ... ation.html
http://www.martinfowler.com/bliki/Event ... ption.html
http://www.samoht.com/wiki_downloads/St ... cyCode.ppt
http://scottmark.blogspot.com/2006/01/g ... glers.html
It is always interesting to learn something new -- especially patterns because the are not just a solution to a set of problems, but a way to talk about the problems and solutions. The solution that I implemented in the past, and described up above, is essentially implementing the StranglerApplication pattern -- I just didn't know the name or have all the helpful information surrounding it. Hence my solutions were not that good, but they will now improve thanks to Jenk!
An essential part of a StranglerApplication is to implement the EventInterception pattern. For web applications that often means a new entry point and new URLs for the StranglerApplication. As I described above, implementing a Front Controller (or second Front Controller) is the simplest way to do this in web applications.
Re: spaghetti to mvc
Posted: Thu Nov 13, 2008 12:18 pm
by alex.barylski
but a way to talk about the problems and solutions.
That is what I find most useful...the solutions are usually pretty obvious...but having the vocabulary makes communicating, discussing ideas, documentation and understanding in general more thourough.
Hence my solutions were not that good, but they will now improve.
I would say the solutions are probably just as good...but the understanding is improved which is what makes the biggest difference.
The fastest, cheapest, simplest, most efficient solution is always the best...but understanding that solution so you might apply it again and again without a second dought is what I find most powerful.
Re: spaghetti to mvc
Posted: Thu Nov 13, 2008 4:00 pm
by Christopher
PCSpectra wrote:I would say the solutions are probably just as good...but the understanding is improved which is what makes the biggest difference.
No, I had missed a couple of important insights --
AssetCapture being the biggest.
PCSpectra wrote:The fastest, cheapest, simplest, most efficient solution is always the best...
In my experience it is the best solution that is always the best ... and it is often neither fast, cheap, simple nor the most efficient ...