The Application Code Reviewer (ACR) is a tool built for developers to help with code review. It scans a Mendix project and detects potential bugs, smelly code, security vulnerabilities and more. ACR does this by comparing a Mendix project against a database of development rules based on Mendix best practices and community guidelines.
Automatic code reviews deliver the best value when used by team members during development and ideally as part of a continuous integration pipeline. This post tries to look at some strategies on how to best adopt ACR and get the most benefit out of it.
When to do code reviews?
Code reviews should be done as early as possible in the development cycle. Ideally, when development on a user story is finished the developers should scan their Mendix project for violations and fix them before committing to the team server. This keeps the code base clean.
In addition to manual scans done by developers, it is recommended to do at least one scheduled scan per day. Schedule this scan to run at the end of a work day against the latest revision. This gives representative historic data for the code quality of the project over time.
The trend-line shows the number of violations per category for each revision.
Using ACR on a project
When introducing any tool to a project it makes a big difference if this is a new or an existing project (also called green and brown field respectively).
Green field projects
So you are starting a new project from scratch. Lucky you! And you have decided to do this one right, so it has to have CI/CD, testing, code reviews, etc. You know all the good stuff that every project needs to be a success. Using ACR on a green field project is fairly straightforward.
As soon as ACR finds a rule violation fix it asap or add it to the white-list. In terms of overall code quality, try to keep module encapsulation to above 60-80 percent and size to medium and finally aim for 80-60 code coverage. If module encapsulation drops too much then its time to put on your refactoring hat. When a module becomes too big consider peeling off functionality or splitting it, divide and conquer style. If test coverage is too low, well.. then write more tests.
Brown field project
The challenge with using ACR on an existing project is that the initial scan will reveal hundreds or maybe even thousands of violations. This is only logical, since a project that has seen active development without an automated code review tool, accumulates violations over time. To fix all the violations could take weeks. However, it is often not possible to justify stopping all active development for several weeks to fix violations that only developers can see. The solution is to adopt the ratchet methodology.
A ratchet is a mechanical device that allows motion in only one direction while preventing motion in the opposite direction.
With this methodology developers are required to keep the total number of violations in the project either the same or lower with every new version. This serves a dual purpose. For one, new code will tend to have very little violations. On the other hand developers will work towards fixing violations in existing code gradually as a safe guard, to keep the total lower in case the new code that they write triggers a violation.
It has been shown that projects that adopt this methodology see a gradual, but continuous reduction in the number of violations over time and with that increase in the code quality.
Communication and fostering adoption
In order to successfully introduce a new tool to your development workflow communication is essential. Make sure that all teams and all team members are aware of the existence of the tool and where to find it. Everyone should know what the tool can do for them; when they are expected to use it and how they need to act on findings from the tool.
In some cases certain team members struggle to adopt or flat out reject static code analysis, due to skepticism. I personally was once a non-believer. To overcome this, pick a few violations from that developers latest revision discovered by ACR and go to that developer and show them what ACR found. The developers will either fix the violations or start a discussion about what development rules are checked. In any case, that developer will start paying more attention to ACR in the future.
Summary
Doing an automatic code review early during development is one of most effective ways to improve code quality. When dealing with existing or legacy project use the ratchet methodology and focus on newly discovered violations. Finally, establish goals for quality, e.g. over 60% module encapsulation, and communicate them clearly with the entire development team.
I hope you enjoyed reading this post and that it helps you to build better applications. If you have any questions, please feel free to contact me.
Get in touch
