5 automated ways to ensure Code Quality

???? Ver versión en Espa?ol ????.

Ensuring code quality is essential, and as a QAE or SDET, you must provide your team with automated tools to guarantee it. Although many consider this an aesthetic or style issue, it can affect productivity and lead to poor decisions. This matter is so important that numerous programming experts never miss an opportunity to emphasize it:

?

“The ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. Making it easy to read makes it easier to write”. ~ Robert C. Martin (a.k.a. Uncle Bob).

?

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” ~Martin Fowler?.

?

This article introduces these concepts; in future articles, I will show you how to implement them technically.

1. Dependency Management

Your project must use up-to-date dependency management software that automates everything necessary for the project to run without manual interventions.

2. Code Style Guides

Each developer has their particular coding style, so it is essential to commit to style guidelines to standardize the code. Implement tools that format the code as you write it, such as IDE plugins, and configure them to apply automatically during pre-commit and pre-push processes.

For legacy projects or projects with extensive codebases, it is best to apply style analysis only to recently changed code according to the version control system (CVS or git). Add linting systems for auxiliary project languages such as CSS, SQL, XML, JSON, etc.

3. Static Code Analysis - SonarQube

The SonarLint plugin, available for almost all IDEs, will help you standardize the code and prevent code smells and logic bugs (not business rules bugs) as you write. Meanwhile, SonarQube offers a more profound analysis to improve readability, maintainability, security, code duplication, and test coverage and provides solutions.

SonarQube is not a security analysis tool, but it helps reduce the probability of exposure.

4. Preventing Non-Standardized Codes from Being Promoted

GitHub Actions

As a QAE or SDET, you must implement cache management for quick results. Remember, the most effective test is the one that delivers results quickly. Configure the GitHub Action to stop at the first error to maintain productivity. Ensure that code merging is enabled only after passing the GitHub Action.

Peer Review

The developer must include a screenshot of SonarQube's Quality Gate in the PR. This helps reviewers focus on providing real improvements, not issues that tools could have flagged. The review should be done by at least two people, including the technical lead. If the code lacks unit tests, the second reviewer should be the 'godparent' of the affected module. Configure it so that merging is blocked until the required approvals are obtained.

5. Jenkins and Other Continuous Integration Systems

As a QAE or SDET, it is crucial to implement cache management to optimize the continuous integration process. Ensure the rules are applied in both the CVS and the continuous integration system to prevent bypass. While it may seem repetitive, the continuous integration system will execute fewer tests than the CVS. Finally, enable report generation from the continuous integration system to effectively monitor quality control.

Opportunity to Develop Skills in Engineering Teams

Suggestions for using other standards

Evaluate the proposed options as a team, considering the standards' characteristics, such as the community's size and frequency of improvements.

Implementation of Specific Rules

This is an opportunity for the team to grow. The team member suggesting the change must promote it within the standard, developing social and technical skills to benefit both the team and the team member’s future.

APPENDIX: Recommended Technologies Table

?

The following table presents a list of technologies that will allow you to expand your knowledge while I publish the upcoming articles detailing each implementation step.

?

Sources

?

The text is an original work based on experience.

The image comes from Stop Using Else in Your Programs by Joey Colon.