Code Quality Control And Why You Need It
If companies don't measure source code quality, how do they know if they're building software effectively? Poor code quality deteriorates productivity and efficiency.
Join the DZone community and get the full member experience.Join For Free
Code Quality is an important thing, right? Everyone knows that. And everyone agrees on that.
So, why do most software companies:
- have no Code Quality definition,
- use Code Quality standards inconsistently,
- or 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 articles 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?
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 efforts 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 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.
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, which will be covered in a future article.
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!
Published at DZone with permission of Artur Kluz. See the original article here.
Opinions expressed by DZone contributors are their own.