Do you know what code quality really is?

Introduction

Sometimes I feel like it is not easy to define what “code quality” is.

I can recognize high quality code by intuition, but I sometimes don’t even know what I mean. So I have to stop and think about “quality”.

The word “quality” is thrown around so much that it’s easy to lose sight of what it means.

In the case of code, quality is about producing clean, efficient code, that solves your customer problems for the long term.

¿Sounds simple? Technically, it is.

Code quality is a lot more than just testing.

Sure, testing is a big part of it, but there’s more to quality than that.

Code quality encompasses everything from the code being simple and predictable to how easy it is for someone new to get started with your project.

In other words, good code looks the way you expect it to look when you read through it once or twice; bad code makes you scratch your head and wonder what happened between writing one line of code and seeing its effect in production.

We all know that meme about the WTFs per minute.

There is more to quality than testing, but in code, testing is at the backbone of code quality, so let’s start there.

When you have a feature request, the first thing you should do is write tests.

In coding, tests come first.

It is very simple: you need to know how to know when you have got it to be able to know that you have got it.

So without some form of test, you don’t even know if you are actually doing things right.

Tests help you straight-line towards high quality code, by following a variation of this simple process:

• Write the test first and make it a failing test. That way, you know what your code has to do before writing the actual code.
• Write the production code to pass those tests.
• Sometimes, you will make changes in production that will make other tests fail.
• Run the failing test and watch it fail. 😈This will give you an idea of how much work there is left to do before everything works as expected again.
• Once your new feature passes all its own tests, go back through each file that was changed, and make sure that the code is what you would expect it to be. Get rid of all the head scratching names and clever but difficult to understand implementations, unless they are NEEDED.

Test-driven development helps you think through the requirements and develop simple code.

In a nutshell, test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, then it is refactored and then the process repeats.

The cycle should be kept small so that changes are easy to undo and you don’t get lost.

The idea is that by writing tests first you can catch a lot of bugs before they occur and make sure your code works with different scenarios.

And as a huge bonus: As you write the tests, you get to decide how the production code will look like. Talk about being able to make it “read like prose”!

And by the way, the tests should be written before the code, but they don’t have to be written in stone.

You can change them as you go along, because, in a sense, you are using your test code to test your production code and you are using your production code to test your test code.

Who watches the watchmen? I don’t know about that. But I know that production code tests the test code… as you make all of your code read as if your life depended on the famous “next guy” understanding exactly how your code works.

Unit tests help you keep your code modular and flexible.

Unit tests are a great way to understand what your code is doing. They also help you stay organized and modular, which makes it easier to make changes in the future. If you don’t have tests, it becomes difficult to know if your changes broke anything or not.

When you have tests, it’s easier to make changes because you know that your code still works as expected. When your code doesn’t work anymore (for example, because of a bug), the tests will tell you exactly where the problem is. And if you keep your development cycle short, you can easily go back to a working version of the code at any point without having to backtrack too much.

The longer you or your team waits to refactor legacy or smelly code, the more expensive it becomes (and the harder the change is).

If you’re a developer, you probably know that code quality is important. If your team doesn’t already have a clear definition of what “good code” looks like, it may be time for some new best practices around writing clean, maintainable code.

By the way: you always have time to refactor.

ABF, Always Be Refactorin’
- Blake, Glengarry Glen Ross

But what if I told you there was an even more important reason to focus on improving the quality of your software?

The longer you or your team waits to refactor legacy or smelly code, the more expensive it becomes. The longer it takes to refactor legacy and smelly code into well-written, efficient, and loosely coupled components, the harder it will be to do so later on down the road (or even worse — the longer this type of low-quality work gets left in place).

And as a developer, the more you wait, the more you will have to work to get your code back to “clean”.

The reason? As time passes — and systems grow larger — they become increasingly complex and difficult to maintain. As they grow less manageable over time due to increased complexity and broken dependencies between components in large applications that are built with lots of different technologies (i.e., web apps), debugging becomes harder as well because developers spend more time working around bugs instead of adding value by building new features that help their business succeed!

And hiring new developers helps a little (if you can stand the initial cost of actually going slower), but is not the solution.

So, what can we do about this?

How do we prevent our code from getting worse over time? The answer is simple: refactor legacy and smelly code into well-written components that are easy to understand and maintain.

Do it one component at a time, as you work on your system… just leave everything better than you found it, and your code will eventually end up completely clean (especially where it matters).

And don’t skip refactoring. That is like a surgeon skipping on washing his hands. There is always time to refactor.

The code should be as flexible as possible.

The most important thing to remember when writing code is that it should be as flexible as possible.

Flexibility is even more important than writing code that works.

If you only write code that works in the current situation, then it will be hard to change it when requirements change. It will become dead code. A waste.

If your code is flexible, it is easy to make it work even if it does not work, or when the requirements eventually change (and they will change).

In Code, quality must always come first.

What most software developers don’t realize is that code quality isn’t second to having “working code”.

Managers, clients and stakeholders may want you to deliver fast, but that is no excuse to deliver ugly, confusing, smelly code.

Change the scope or change the plan if necessary, but don’t EVER give in to the temptation of delivering low quality code. It does not have to be perfect, but it has to be good enough. And “just working” is definitely not good enough, unless you plan on throwing that code away in the future.

Code quality is a holistic approach to software development that encompasses all aspects of the process, including requirements, design, architecture, and documentation.

Testing is just one aspect of code quality — it’s not even the most important aspect! Code quality is about your code being resilient, easy to maintain, flexible and easy to read.

High quality code is… what you expect it to be. And you have to work to make it that way. Think about that.

Having clear requirements and working on one feature at a time, working fast but without hurries, having clear communication… all that goes into the quality of your code.

If a manager doesn’t communicate, hides things or even lies… we can obviously not write high-quality code.

But we, as developers, can make sure that our code is still as high quality as we can by keeping it clean.

Conclusion

Code quality is more than simple bugs and regressions. Code quality is about the overall health of a project, from testing to documentation and even one to one communication. It’s about how you write your code and manage it.

Code quality is a team work between managers, clients, developers and other stakeholders.

Code quality is not a simple matter. And that is maybe why sometimes I feel like it is not easy to define what “code quality” is.