@Matthew by far, Jared's answer is the better one. But coming with that is the need to manage the boss's stress levels.
meh, it depends on the culture of the place you work at and how critical and complex the app is. If you've identified all the "gold code"** and can prove you can change it and not disapear down a rabbit hole of fixing and refixing then selling the idea of wholesale changes might be easier: a mini project to breathe new life (and longevity) into it. I think we're all assuming that this app is a money-spinner/has a long life in front of it/you've sold the boss on the time saved in future maintance and enhancements. If the boss is truly sold, then Jared's is the better answer. But if not, then you're just going to have to eat that elephant one mouthful at a time - if only to save your sanity every time you open up the spaghetti tin to fix something... ** critical code that took a lot of hard work to get right - the really precious bits. On Wed, Feb 4, 2009 at 9:03 PM, Jared Rypka-Hauer <[email protected]> wrote: > > Fair enough. While I agree that the idea of having to rewrite all > those URLs is certainly daunting, the refactoring job would take .1 > the time because you would have to change so little to gain so much > encapsulation and cohesion, even in a procedural codebase, and in > doing so you would get to know the application which would, in turn, > make refactoring the model to CFCs just that much easier. > > I did this once. I refactored a small spaghetti-code CMS into a > Fusebox application. The best example was the 11 main section pages... > they were all identical except for some hard coded text... so I took > the 11 templates, chopped the query into one fuse, and the UI into > another fuse. Then I created 11 other fuses that created the hardcoded > text and included the other 2 fuses. With one more fuse to handle > layout so I could wrap the main part of the view in the HTML and body > tags and stuff, I was able to go from 11 redundant files to 3 CFM > files, 3 circuits for plumbing and 11 carbon-copy fuses that used the > XML vocabulary to create 2 variables. Best example of Fusebox as a > refactoring tool ever. > > As for having to handle all those URLs, well, if you were to set up > the ColdFusion 404 error page you could do a quick and easy lookup > against a struct. I honestly think that if you came up with a naming > convention for your circuits so the circuit name could be extrapolated > from the file name, you wouldn't have much to worry about. > > OK, so I've said my piece and probably irritated everyone no end... > please don't think I'm trying to cram frameworks down anyone's throat. > I just wouldn't want you to miss an opportunity and informed consent > is really important... so now that I've spilled my guts I'll leave it > alone. I promise. :D > > J > > On Feb 4, 2009, at 2:00 AM, Barry Beattie wrote: >> >> how about something simple but widespread? >> >> keep it procedural and move as much processing as possible into >> functions within CFC's. Don't bother thinking they're objects yet, >> just collections of functions. ... > > > On Feb 3, 2009, at 11:35 PM, Matthew wrote: >> >> @Jared: thanks for the tips. I am on CF7. I'm not too keen on the idea >> of introducing FB (one immediate concern is that there would be so >> many URL to re-write [which I know could be handled in CF or via >> something like Isapi ReWrite but this introduces another job]). My >> main reason for migrating to OOP are the obvious reusability and >> scalability. Currently the app has a lot of duplicate queries, >> procedures so when you change something in one area if you don't know >> the app the other area will remain unchanged and wrong. I feel that >> once an OOP MODEL layer is in place (with a simple listener layer >> talking to the model layer) it will be much easier one day to >> introduce a framework. >> >> Anyone else got 2 cents to throw in? >> >> Cheers >> Matthew > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
