Mike Borozdin (mike.borozdin at cloudreach)
The code review is a convenient way to ensure that code adheres to high quality standards. Code reviews provide a number of benefits. First of all, they help to make sure that every piece of code complies with company's/team's standards. 'Standards' should not be read only as guidelines for naming variables and code formatting, instead they may include such things, as design patterns and various approaches for writing code for a specific domain, language or a framework.
Secondly, a code review session can unearth potential problems with code and mitigate them at the early stages of a product life cycle.
Another interesting aspect of having code reviews is that they help to spread knowledge about an entire code base. Indeed, not every developer is given a chance to work on every part of a product and sometimes developers might have limited knowledge about parts of application that have not been written by them. Performing a code review provides such an opportunity and fosters having a better overview of the whole code base.
Finally, code reviews bring a great learning value and help us to become better developers. Often, a code review can trigger a good piece of advice from a peer.
In spite of the aforementioned benefits, code reviews are known to be time consuming and more importantly irregular events. However, these drawbacks can be avoided when performing asynchronous code reviews. The idea is inspired by the way GitHub works.
An asynchronous code review does not require the whole development team to be present at the same time in the same place. It only requires one other developer who can have a look at a piece of code, when they have a minute.
Furthermore, it is possible to make such a process mandatory and have every bit of code reviewed. This is also inspired by Github and the way many open-source projects accept contribution via pull requests.
No matter which source control management system (SCM) is used there is typically one main development branch and multiple features branches. Usually, a developer when finishing a feature would merge it into the main development branch. However, when doing asynchronous code reviews, a developer would not merge it, instead they would push it to a remote branch on GitHub and create a pull request.
Then, another developer would review code and leave their comments. The first developer would read the comments, introduce necessary changes and push it back to GitHub. The process continues until the reviewer is satisfied with submitted code.
Please note, that even though we give examples related to Git and GitHub, we believe it is possible to have asynchronous code reviews with any other SCM. After all, is is more about an efficient process, than underlying technology.
No comments:
Post a Comment