Editor’s Note: This is the first in a five-part blog series on refactoring and modernizing PHP applications.
We’ve all heard the expression from the children’s story: “slow and steady wins the race.” But what does this have to do with refactoring? And how can this help us to modernize our applications?
First, a little background: Aesop’s fables about a tortoise and a hare is where this proverb originates. The hare makes fun of the tortoise about being slow, and is challenged to a race. The hare takes off, building a commanding lead, and decides to take a nap. He awakens only to find the tortoise close to the finish line, and tries frantically to catch up, only to lose the race to the sluggish turtle. The moral of the story? Slow and steady wins the race.
When it comes to refactoring, slow and steady is the way to go. Like the hare, sometimes we’re so excited about a new refactoring project that we dart out ahead, pushing forward and trying our best to refactor the whole project at once. But here lies danger: inevitably, we’ll make a mistake, introduce a bug, cause ourselves some kind of problem.
Rather, we should be more like the tortoise. Slow, consistent, methodical. We shouldn’t rush to make changes in our application; instead, we should carefully consider just what needs to be done, and then do it, with intent and purpose.
What does this look like in practice? We want to make one change at a time, and the most importantly, test and commit that change before making another one. Making two changes or more at any given time opens us up to introducing bugs that we can’t easily solve, because we won’t be sure which change caused the issue. While it might seem easy to make two changes at a time, something we can easily handle, this approach will cause problems. We will introduce bugs. It’s important for us to make single, solitary changes, commit and test them, and then move forward with the next change.
If we do this, we slowly, slowly, too slowly build up progress towards our ultimate goal: fully refactoring our application and making it better. Of course, one small, solitary change isn’t going to make the application into what we want it to look like. We have to work at it, and it takes time. Sometimes it can feel painfully slow. But over time, the application will slowly transform, and we can take pride in that as it happens.
Slow and steady is not just for children’s stories. It applies to refactoring as well. It’s important for us to recognize and respect the protocol, because making too many changes all at the same time will produce chaos, and worse, bugs.
Frustrated with your company’s development practices?
You don't have to be!
No matter what the issues are, they can be fixed. You can begin to shed light on these issues with my handy checklist.
Plus, I'll help you with strategies to approach the issues at the organization level and "punch above your weight."