Code Quality Control And Why You Need It

Code Quality is an important thing, right? Everyone knows that. And everyone agrees on that.

So, why most software companies (What Do Developers Themselves Say about Code Quality?):

• have no Code Quality definition,
• use Code Quality standards inconsistently,
• don’t measure their Code Quality.

In this article, I am going to focus on the 3rd problem mentioned, which is the lack of control over Code Quality. Two first bullets are of course important too but I will cover those in a separate article someday.

So if companies do not measure the quality of source code, then how do they know if they are building software effectively? Poor code quality deteriorates productivity and software building process efficiency.

Moreover, are they aware of the fact that their Technical Debt (definition) might be growing? And, as a result, the cost of adding new functionalities is growing too?

Technical Debt

There are hundreds of articles about technical debt but I found this one by Martin Fowler the most complete and pragmatic.

So, what are the consequences of not paying the Technical Debt off (or in other words not making the code better or more solid)?

In short, the less you care about your code by NOT:

• coding according to best practices,
• checking your code quality metrics,
• testing your code properly,
• doing anything to improve your code quality (refactoring),

the more time and effort you will be spending on maintenance of the code instead of on development.

This might not be visible at the beginning but will become crystal clear in time.

That was a kind of financial view on the consequences of poor code quality.

But let’s have a quick view on this problem from our – software developers’ – perspective.

What do poor code quality and high technical debt mean to us?

• Increased level of stress as deadlines are tight as always. But adding anything to the code takes more and more time, and becomes riskier and riskier every day.
• Increased level of stress pt. 2 because the on-call weekend is coming? And you are wondering if something blows up in production…again?
• Tedious, boring, and overwhelming duty instead of a creative and satisfying job that it used to be,
• “Why will this take that much time” a question repeated by management more and more often,
• Frustration caused by working with shitty code. You know it, right? 😉

Alright, so now we know how bad it can be if we do not care about our code enough. But what can we do about it?

Code Quality Control Process

I am pretty sure you know that there is no magical stick that can change bad code into a solid one. Especially in one day.

But it doesn’t mean we can’t do anything.

We can build a process. A series of repeatable steps that:

• help to keep Code Quality on a high level for the projects where the quality is already satisfying,
• show what, where, and how to change in existing code to improve its quality.

However, doing everything manually is not the best option.

Firstly it is not efficient. Secondly, it is error-prone.

Have you ever missed an obvious bug in code during code review?

Well, I have… 🙁

Moreover, the bug wasn’t discovered while testing (manual of course) and popped up on day one in production…

Automation Is The Key

So, having a Code Checking Process that is manual doesn’t make any huge difference. What we need is automation.

Automation can take the burden of constantly checking your code off your shoulders. And let you focus on solving real-life problems using the software, not solving the problems of the software itself.

Many tools in the Java world can help you with automating code quality checking and improving.

OK, I do not know any tool that can convert your legacy, poorly designed, and poorly coded project, into a nicely organized and easily maintainable one. At least not at once 😉 And not everything can be fully automated (e.g. code reviews).

But, we can get rid of many difficult-to-spot code errors and make our code cleaner and more SOLID at the very beginning of the cycle (SDLC)? 

More importantly, by automating the process, we can achieve that using only a small amount of effort and time as compared to the manual option.

And, all that, before the QA Team put their hands on it 😉

What to check

Now we know that we need a process. Moreover, we know that it should be as automatic as possible. But what should we check?

We can divide the whole process of source code checking into 7 areas:

• code style checking
• code correctness checking and common mistakes catching
• design flaws identification
• code complexity calculation
• code and dependencies security scanning
• code coverage calculation
• code review

Each of these steps requires a bit longer explanation. So, if you want to learn more about I encourage you to read another article How To Keep Code Quality Under Control In 7 Steps.

Summary

The Quality of Code is a very broad topic and there are many different opinions about it. But no matter what you think about code quality, it does impact our (developers) lives anyway.

It can increase the quality of our lives or make it worse. You can feel proud of your code or you can feel ashamed. You can solve real-life problems or do tedious and repeatable tasks every day.

It is not enough to educate developers, organize trainings, or give presentations about code quality. Having a Code Quality Assurance process is a must if the company is serious about building software. Even in all-star dev teams.

If you like this article and don’t want to miss the next articles please sign up for the newsletter.

Thanks for reading and till the next time!