Nowadays it has become very popular to drive projects in an agile methodology. Together with this approach it brings developers an option to create small, iterative steps in order to build the final product. Usually these steps take form in popular “Pull Requests”, or PRs as developers sometimes use.
Pull Request is generally just some change one developer has done to the codebase (no matter how small) in order to implement a feature, or maybe fix a bug. This change should not be added to the codebase immediately though. Even if we have professionals in our team and we do use source code version control, together with the division into branches (release, development, etc.), it is not a good idea to merge new code changes immediately.
It may happen that there is a mistake in the code, that the developer would like to merge into codebase and without some kind of control, these mistakes (often referred to as “bugs”) would get propagated and we would have to hunt them later. It has been shown by experience that if another pair of eyes verifies that this particular change is correct, it reduces the amount of bugs in the code by a great deal.
That is why Pull Requests have been invented. In principle, you as a developer will create a so-called Pull Request in a version control system (everybody uses Git nowadays anyway) and his work is done, even though the code change is not propagated to the code base. Another developer must come and manually verify that the code is healthy and click on the “Approve & Merge” button in order to apply it to the code base.
Now this can be a lot of work and a lot of developers don’t have time for that, right? Well even if it is a best practice, we cannot blame overloaded senior developers to click on these buttons without checking the code itself. But if they do, bugs will breed and sooner or later it can overwhelm us.
Now comes our tip of the day: Automatize!
Nowadays it is quite common to have some kind of CI/CD pipeline in your project (Continuous Integration/Continuous Delivery = it will pack itself, it will test itself, it will deploy itself). Well part of that pipeline can be a static code review tool like SonarQubeIntegration of such a tool is surprisingly easy and even though it ain’t a silver bullet,
it can help you a lot. Especially if you will write your own rules for code review.
If you have your own Github/Bitbucket/AzureDevOps/GitLab account with a repository you can set it up in 5 minutes right now! Just head over to the https://sonarcloud.io/og in, connect your repository and create new Pull Requests. SonarQube will check them for you automatically. Of course this is not the only static code review tool on the market. There are many others: PullRequest or Codacyand many others. Take your pick.
Be careful though. Even if this can be a handy tool, this should never replace another developer’s review. There are ways to create code changes that shine in green light under static code review, but are very dangerous in fact. You can check my example Pull Requests here: https://github.com/apelttom/java_and_sonarQube/pulls
Happy Hacking!
