Skip to content

Métricas de evaluación de calidad de código

Jose Luis Delgado Davara edited this page Jul 23, 2017 · 2 revisions

Estas son las métricas utilizadas en el rubro de evaluación de calidad técnica de las herramientas digitales de Código para el Desarrollo. Aquí puedes ver más información sobre el rubro.

Definición de las métricas


Blocker issues

The maximum blocker issues is 0. It is very important to ensure that all blocker issues has been fixed due to the fact that this type of issues are bug with a high probability to impact the behavior of the application in production: memory leak, open JDBC connections... The code MUST be immediately fixed.

Duplicated lines (%)

This metric shows the number of physical lines touched by duplication. It is very important reduce this metric to the minimum and keep away the spaghetti code. This spaghetti code usually leads to a number of duplicated lines higher than 25%.

New critical issues since last version

This term makes reference to the generation of new issues of status Critical since the last version. What New critical issues really measures is how good is the code compared to the last time that the sonar analysis was run.

Public documented API (%)

A low percentage of commented public methods entails that the development team has ignored the documentation guide. It is very important to make this value higher than the 50% to make sure that the code is maintained when the development team changes.

Technical debt

The Technical debt is the number of man-days needed to fix all problems in the code base. It can be seen as the amount of effort that a team must invest in order to carry the application to a determined quality policy.

Technical Debt Ratio (%)

A product with a technical debt ratio of 5% is clearly in better quality shape than a product with a ratio of 25%. But when is the right time to start worrying about the code quality?

There are different types of projects and every programming language has its own characteristics. A safe rule of thumb is that codebases with a technical debt ratio over 10% should be considered candidates of poor quality. In such cases, the management team should work with the development team to decide how they want to start eliminating the debt.

Test coverage (%)

If the test coverage ratio is lower than the 50% this means that the application has too much functionality that is not being tested on each release. This kind of applications use to have a lot of regression issues.

Esta tabla muestra los estándares adoptados por el proyecto Código para el Desarrollo para evaluar la calidad de escritura del código.

Más información

https://el-bid.github.io/Developers-Guide-for-Creating-Digital-Tools/project-evaluation/evaluation-matrix/