Technical evaluation

IDB digital tools published in Code for Development must fulfill desired requirements. (More information here.)

What is the technical quality of a digital tool?

The technical quality of a digital tool is established to the extent that the writing of the source code and the architecture of the digital tool is free of structural failures that may block its use or reuse and also facilitate understanding in the reading and modification of the Source code.

What main technical characteristics define the quality of a digital tool?

The following characteristics are variables that depend on the context and purpose of the digital tool.

• Flexibility Must be able to function completely and adequately without relying on forced licensing of any type of additional component.

• Portability It must be able to function completely and properly in different operating systems, especially those that do not imply additional licensing costs and that have regular security updates for free, for example: some distributions of Linux and / or BSD systems.

• Scalability You must have documentation, reports and / or tools that allow you to determine adequately the costs and considerations associated with the scaling of the solution.

• Interoperability It must have at least one mechanism that allows interconnection and interoperability with different existing and future systems, for example: API, RPC, SDK, etc.

• Licensing It must be published under a licensing scheme that allows its deployment and use in different contexts and use cases. For more information about licensing your tool visit the section.

What is continuous integration of code?

Continuous integration is a software development practice where members of a team integrate their work frequently, usually each person is integrated at least daily, which leads to multiple integrations per day. Each integration is verified by an automated compilation (including the test) to detect integration errors as quickly as possible.

Why is continuous code integration important?

Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more quickly.

To read more about this topic, we recommend you visit Martin Fowler’s website https://www.martinfowler.com/, who proposed the model.

What continuous code integration tools do we recommend?

There are many continuous integration tools, in this guide we recommend two:

• Travis CI It is a hosted and distributed continuous integration service used to test software projects hosted on GitHub. Open source projects can be tested at no charge through travis-ci.org and private projects can be tested at travis-ci.com at a charge. https://travis-ci.org/

If you want to configure travis in your github project, start here: https://docs.travis-ci.com/user/languages

• Jenkins is a Open Source continuous integration software written in Java. It is based on the Hudson project and is, depending on the vision, a project fork or simply a name change.

Jenkins provides continuous integration for software development. It is a system running on a server that is a servlet container, such as Apache Tomcat. It supports version control tools such as CVS, Subversion, Git, Mercurial, Perforce and Clearcase and can run projects based on Apache Ant and Apache Maven, as well as shell scripts and Windows batch programs. https://jenkins.io/

in both cases you must configure the builds, which are the packages you need to run a technical quality report.

How to generate reports of technical quality?

Through a static code analysis. This analysis evaluates the understanding of the code through the programming style, the architecture and the documentation of the code itself (commented lines of code).

SonarQube is one of the tools that allow you to control the quality of code as it develops.

What tools are there to evaluate the quality of the code?

There are many tools and each one evaluates different metrics. Here we highlight two:

• Sonaqube is a tool for free use. You can evaluate the quality of the code at a very granular level of detail. It allows you to identify exactly the errors and the lines of code that you can improve. To configure the tool it is necessary to have a repository in Github or Bitbucket and that you know:   * The requirements of the operating system for compilation (specific versions of libraries, package management software and dependencies, SDKs and compilers, etc.).   * The own dependencies of the project, both external and internal (order of compilation of sub-modules, configuration of location of dynamic libraries, etc.).   * The specific steps for the compilation of the source code and execution of unit tests in case the project has them.

• Better Code Hub is also free to use and evaluates more generally the quality of the code. The required configuration is less complex, but the results are more general than with Sonarqube.

What are the most common metrics to evaluate technical quality?

Although there are many metrics that vary according to the tool used, the most common are:

• Blocker Issues: Number of problems in writing the code with high severity. These problems can be operational or security that can make the digital tool unstable in production.

• Duplicated lines: Number of duplicate lines in the code.

• Critical Issues: Number of problems in writing the code with critical severity. These problems can cause unexpected behavior of the tool in production without impacting the integrity of the complete tool.

• Public documented API: Number of classes, functions and properties documented.

• Technical debt: Effort needed to solve all the problems at the base of the code. It is measured in work days and is a metric that calculates the SonarQube system.

• Technical debt ratio: Difference between the cost of developing the digital tool and the cost of solving your problems.

• Test coverage: Percentage of the code that has been tested.

In this page you can find more information on each of the indicators used by SonarQube. In the Publication Guide you can see a table with the evaluation item used in the IDB.

How is software developed for easy maintenance?

There is a lot of documentation on how to develop software. It covers topics that range from architecture to the technologies that are used. In this guide we mention the 10 guidelines obtained from the * Software Improvement Group’s industry benchmark , which are defined in the book *Building Maintainable Software, Java Edition - Ten Guidelines for Future-Proof Code

• Write short code units: Short units are easier to understand.

• Write simple code units: Simple units are easier to test.

• Write the code once: The duplicate code means duplicate errors and duplication of changes.

• Maintain small unit interfaces: Units with small interfaces are easier to reuse.

• Separate responsibilities in separate modules: Modules with a single responsibility are easier to change.

• Pair of architectural components loosely: Independent components can be kept isolated.

• Keep architectural components balanced: A balanced architecture makes it easier to find your way.

• Keep your code base small: A small code base requires less effort to maintain.

• Automate tests: Automated tests are repeatable and help prevent errors.

• Write clean code: “Leave the camp cleaner than you found it.”

What are the technical requirements for publishing IDB digital tools?

To publish IDB digital tools in Code for Development it is necessary that the tool meets the desirable requirements. You can find more information in the IDB Publication Guide.