At our giftsforengineers.com site, we use ZenCart for the front end, but 100% of our backend was written by me. In the course of working through some personnel changes here, it's forced me to take on additional responsibilities which have also caused me to take a closer look at my own code. The majority of my code was written some 6 years ago, with some additional modules added on as needed as the years went by. It's clear to me that our whole system could use some major reworking, if not a complete rewrite.
I know how I personally tackle a project like this but I am looking for helpful resources and some different perspectives before I jump in. I considered purchasing Martin Fowler's "Refactoring" book, and I already have "Code Complete" -- but I'm really looking for new-ish articles from other people. I think my database is fine, so I don't see this as an issue... what I'm really looking for are good articles on refactoring code. I've googled and found a few things, but I'd like to get an opinion from the peanut gallery. Feel free to comment here, or you can send me a tweet to @ElizabethN.
Michael Feathers "Working Effectively with Legacy Code" is something I just picked up last week. Not too far in to it yet, but helpful. Read some other reviews too and see what you think...
Feathers' book is well worth the money and time. It is a fantastic book that really changes the way you look at the code you wrote "yesterday."
I think this book also helps you:
I picked up some good refactoring knowledge from Fowler's book (which I consider Required Reading ;) as well as Kent Beck's "Test-Driven Development". I also have Feathers' book as suggested by Kimsal, though I only made an initial start into reading its refactoring strategies before having to move on to something else.
Given the time to do so, I'd suggest Fowler->Beck->Feathers, but if time is short, you might do better to dive right into Feathers since it lays out specific strategies for refactoring specific scenarios of legacy code. If you can recognize the scenarios in your code, you can apply the refactoring strategies that apply. However, I think I understood more easily the ideas in Feathers _because_ I'd already read Fowler and Beck. If you go this second route, you might consider tackling Beck next (it's shorter than Fowler) to reinforce what you pick up from Feathers.
I would also opt for Martin Fowlers' book and as a follow-up read you might consider the 'Refactoring Workbook' written by W.C. Wake. Or just take a look at the online refactoring cataloque, which describes the refactorings covered in Fowlers' book plus additional, new ones discovered by others authors/developers.
I'm not familiar with Feathers, so I can't speak to it, but Refactoring is an excellent, excellent place to start. Using that as a base, I would venture out to Refactoring to Patterns. Beck's Test Driven Development is also an excellent source on that process if you're unfamiliar with it. Having unit tests in place is paramount to a success refactoring session.
This is not a book recommendation, but it's probably something you'll find in all of them:
Something that can really help when doing major refactoring is a solid set of automated tests, ideally unit tests but any type will do. If you have that, you can easily make drastic changes without worrying about things breaking under your nose; you'll know instantly from the tests!
This is something that PHP actually supports less than well... As a practical matter, there are two core issues:
1. Forward only - The lack of true strong typing ⊃
2. No compiler - As you start to change your class methods and inheritance relationships, you're going to blow something up someplace. The problem is, you're not going to find out about it until you executing through the exactly code path/state that results in a PHP fatal error because a function and/or class reference is no longer correct. This is the low-level issue that drives the thought process I mentioned in #1. It's a pain, but you need to have your operations procedures around detecting and resolving PHP fatals nailed down. (And, yes of course testing techniques can help mitigate this, but they won't eliminate this condition - besides nailing this down will help you accomplish your refactoring anyway. Any refactoring of significant complexity will be subject to this issue.)
Have fun... :)
I've been pulling forward a large code base, undergoing constant extensions, through every PHP release since 4.3.8, taking advantage of new features as they became available. So it can be done, you just need to write the most defensive code you've ever written...
Andrew