Help! I’m drowning in legacy code!
It never fails. Someone will write me after reading my book or taking a class with the same story. They were so jazzed: they felt like they were on top of the world, ready to attack their next programming task with vigor! They had studied hard, connections had been made, understandings had been formed. And then, inevitably, reality sets in. They look at their code, same as it was before, and realize: this is going to be harder than I thought.
It can be easy to feel dejected when looking at a pile of code you inherited from four generations of programmer ago. None of the best practices or principles. No tests. Hell, you’re lucky if you even have objects that don’t rely on PHP 4 style constructors. You’re in legacy code hell.
But there’s hope.
Software as a long game
Even though it can feel hopeless when starting at such a massive pile of crap, there is in fact hope. There is a redemption waiting for you. That redemption is found in a simple revelation: software is a long game.
Consider: that steaming pile of detritus you’re working on didn’t get that way overnight. In fact, it took a long time to get a code base that big together in the first place. Code takes time to grow. Rome wasn’t built in a day, and neither was your application.
PHP has been around for a long time, over 10 years. Much of that time, PHP didn’t many of the features that now make it a world class programming language. Add to that the fact that PHP’s low barrier to entry means that best practices we now take for granted weren’t known let alone followed means there’s lots of in production business-critical code that we’re now responsible for maintaining.
What can you do, today?
But everything doesn’t need to be fixed overnight. In fact, it can’t be fixed overnight, so relax.
Writing software is a long process that takes time. It’s okay – in fact, it’s expected, that you’ll take time to make incremental changes. The first step is to make something better, today, that wasn’t better yesterday. Refactor something small. Create a group of objects that talk to each other a little bit more reasonably. Decouple a few small things. Make incremental improvements.
As you move through the code, you have an opportunity to improve each part of it in small ways. Combined with the fact that new additions you make will adhere to current best practices, over time the code will begin to dramatically improve. That’s how you make a difference in a legacy code base – through small, incremental changes over time.
To defend everything is to defend nothing.
And even though it’s easy to be a perfectionist and think “everything has to be perfect”, that kind of thinking won’t get you where you need to go. Frederick the Great told his men, “to defend everything is to defend nothing.” You have to pick and choose your battles. Maybe you can’t refactor the entire database logic section this week. But if you can refactor one model, one controller, one function or one algorithm, you can make steady, incremental progress. And that’s something.
Learning design patterns doesn't have to suck.
Design patterns open a whole new world of possibilities. So why are you avoiding them? This brand new book will help you finally understand these wonderful programming techiques!Learn design patterns TODAY »