Lunch & Learn: Code Quality Metrics, or how we do excellence
Lunch & Learn session is here again! It’s lunch time and we are in a relaxing and friendly atmosphere at the office, ready to learn something new and meaningful for our work while enjoying a delicious lunch, provided by the company.
Here are colleagues with different roles in the company – QA, back and front-end developers, designers, product owners. The topic of the session is Code Quality Metrics and the tools we use in our team of web developers at Object Systems International.
Static analysis and why it is so important
One of our company values is providing best quality software. We strive for excellence and to help proving that we use static analytics tools. During the recent Lunch & Learn session we talked about whether it makes sense to do static analysis and whether we can extract something useful from the results. In practice, static analysis prevents errors before the code reaches the users and indicates problem areas that need to be improved. In short, static analysis detects bugs before the code is released in real environment. Therefore, this analysis is extremely important in the work of the developer, QA and the whole team.
Why measure anything? Because we all make bugs. Bugs are hiding well in messy code and it’s always difficult when you have a lot of dependencies Sometimes bugs become clear when you add even one more feature. So, can we trust our code?
We use Target process and it keeps track of our way of work. This way we know how many bugs we do per story do we make good estimates and how involved we are in each project and within our team. Managers have clear view of processes, but they don’t have time to read the source code and they only see the results. This way they depend on developer’s evaluation and feedback on assessing it. With our included static analysis tool, they have easy to view reports of the source code and various metrics that are easy to understand.
The useful metrics
Bad code gets to production sometimes. There are many techniques to avoid that and try to block it. In order to provide additional details on potential problems, you can perform a series of measurements and provide solid proof that the code is prone to errors.
Static code analysis may sound really vague but not so accurate are also the estimations and tests and in addition, you could miss something. Using mathematical equations, we can help ourselves with a visual result of our source code.
Let’s talk about metrics and how to calculate them ourselves:
First is so-called Halstead complexity measures. It is the cognitive ability to read code. The underlying assumption of Halstead is that programming requires cognitive efforts(elementary cognitive steps) that can be quantitatively related to operators and operands. Maurice Howard Halstead in 1977 established empirical science of software development.
The second one is LCOM – Lack of Cohesion and it indicates if your class does more than one job. This metric measures how well the methods of a class are related to each other.
The third metric is CYC – Cyclomatic Complexity, which shows linearly independent paths through a program’s source code. It indicates the complexity of a program.
And the last one is Maintainability Index. This software metric shows how easy to support and change your source code is.
Thinking about all these metrics during development helps us to write cleaner code. Most of the newly trending topics relate to solid principles which are tightly coupled with these metrics. Maybe it’s just easier without calculations, but we’ve shown that it may be simple to track them, and useful outcome may arise. For legacy projects you can spot a potential class for refactoring. For a new project you can keep your code clean and easy for maintenance.
The examples of our PHP projects’ reports we showed during the presentation were interesting for the audience. We showed how they look like and what are the metrics we focus on most. We talked about what are the actions we take and by reviewing the results monthly how our code gets better. The way that this works is by including our metrics tool in our CI/CD process and we can easily see it whenever we want without any effort.
The discussion we had at the end of our Lunch & Learn session was on other programming languages and static analytics tools for them. It was an interesting lunch session for all of us, full of knowledge and news skills and spent in a friendly and educational environment.
If you are interested, you could check the presentation below and contact me directly if you have any questions or want to know more.
[embeddoc url=”https://www.objectsystems.com/wp-content/uploads/2020/01/Code-Quality-Metrics.pptx” download=”all” viewer=”microsoft”]
