Three Thoughts on Improving Code Quality in Existing Projects

October 22, 2012

I’m currently working on a project that I inherited from a previous team in which I’m working on improving the code quality. The details aren’t terribly important, but here’s what you need to know to have enough context for this post:

I didn’t design the application, but the client wants to keep the existing design and feature set

The budget only allows for improvements agreed upon during the planning phase – nothing more

The initial codebase was developed by someone else that opted to do things in a less elegant way

As far as the last point is concerned, “less elegant” could be chalked up to laziness, or it could be chalked up to ignorance.

When possible, I try to believe the best rather than assume the worst, so I’ve opted to go with the fact that the team was under a deadline to ship rather than to build an elegant solution.

That said, I think that all developers have found themselves in this position: We’ve inherited – or contributed – to some codebase, looked around, and said:

I wouldn’t have done it that way.

Often times, the implication is that our way is a better way than the way it’s currently done. In some cases, that’s right, but if developers often think this and another developer wrote said code, where does that lead?

Anyway, this is not the first time I’ve found myself in this position, and it certainly won’t be the last, but it seemed like something worth discussing if for no other reason to share my thoughts on it.

First, I think one of the most important things for developers to learn is this:

Your way is not always the right way, but it may be the better way.

I think it’s part of the developer-maturity process. Throughout school and my career, I’ve met a number of developers who are far more concerned with finding theright way to do something rather than a right way to do something.

It’s not a math problem. That is, there’s usually not a single solution – there’s a variety of solutions that work, some of which are more optimal than others, and those are the ones that we should be pursuing.

So what happens when we’re faced with a project that doesn’t allow us to completely overhaul the codebase? Here are three thoughts on how I work on improving code quality in existing projects.

1. Recognize That We Can’t Fix It

Improve what already exists

Honestly, this isn’t completely true. Time and budget permitting, we may have the ability to completely refactor, improve, and practically rebuild the codebase.

But the majority of the time, this isn’t the case.

Instead, I think that it’s important to realize that whatever we’re faced with isn’t necessarily our job to fix. Perhaps we’ve been contracted to add a new set of features, improve one part of the design, or tweak something that already exists.

In that case, I’d argue that our primary responsibility is to do the best job possible in the area in which we’re working. It’s tough, though, right?

I think programmers are naturally inclined to want to improve areas that aren’t necessarily our responsibility.

2. Refactor As Much As We Can

Create a diamond in the rough

As we’re working through your project – be it adding a new feature, tweaking an existing settings, or something similar – I think that it’s okay to refactor as much as we can within the time permitted.

But there’s a caveat to this: We don’t always know what our changes may to do to the rest of the application.

Specifically, refactoring a function may appear to work in the short term, but what if we missed one of the dependencies while doing so? We’ve then broken something that was working with the intent to improve something. It back fires.

Whenever I refactor, there are two rules of thumb that I try to follow:

Refactor the code thatI write

I only refactor something if I’m 100% sure of the consequences.

Nine times out of then, that second rule serves as a guardrail preventing me from messing with something that may end up breaking an existing feature.

3. Leave It Better Than We Found It

Aim for something like this

When you begin tweaking, introducing, or modifying and existing codebase, you may not be able to improve the overall application, but you do have the ability to leave it better than you found it.

See, I think that if an application is poorly coded, I believe we can rationalize writing bad code ourselves under the idea that it was bad to begin with, so who would who ever know?

But I call lack of developer integrity on that.

Instead, the very least we can do is attempt to leave behind somewhat of higher quality that what we found when we arrived. Perhaps our area of code will follow some sort of coding standard, or file organizational scheme. Maybe it will include comments, documentation, or will implement some form of design pattern.

Whatever it is, there will be a stark difference between what we write and was previously existed, and future developers will take note.

Besides, that helps to define a level of developer integrity. If nothing else, aim for it.

I’m sure there’s more to it than this, so feel free to share your approach in the comments.

Join the conversation! 8 Comments

Great points! I often find myself in this situation with my own code. In our line of work, everything is changing so rapidly that constant learning is a must. I regularly look back on code that I wrote 6 months ago and wish I would’ve done it differently. In these cases, because of time constraints, I usually fall under #2 (refactor as much as I can) as I’m a bit more familiar with what effect my changes will have on other parts of the project.

Funny enough, I find myself doing this with my OWN code. Things I wrote even 6 months ago have code structure I wouldn’t touch now. Being that I’ve released a handful of plugins in the repository, it gives me the opportunity to go back and re-factor things as needed, whether it’s due to a bug found by someone or just scratching my own itch.

I see the same thing all the time. I Spent an hour or two just yesterday going back through one of my older plugins in order to fix some security problems. In doing so, I was constantly saying to my self: “why on earth did I do it this way?!”. I’ve come to realize that this happens to everyone, or at least those that actively work on improving their code quality.

Just Getting Started with WordPress?

I write a lot about WordPress development but if you're just getting started, I recommend checking out WPBeginner. They have free training videos, glossary, and more.

WPSessions hosts some of the best WordPress training you’ll find anywhere from many well-known speakers.

If there’s something you’d like to learn, and it’s not already covered here, it’s probably been covered at WPSessions. If you use the special link below you can watch your first session for free and get a steep discount on the full-access VIP membership.