Author
Pablo Ifran
We are rigorous with the code we deliver. Just because? No. We are strict because we are what we deliver. Trustworthy, reliable and clean code make products scalable, clients happy and developers’ experience better.
Since we started writing code more than 10 years ago, we have been refining a well-known process called “code review”. It is useful to deliver neat code, to learn from peers, to improve coding processes, and to transfer knowledge between teams and within the entire company.
Even though code review seems to be a technical and low-level task, reality is, quite the opposite. We feel comfortable saying that it is a human communication process.
The 3-step process for code review
We use Github for code review. It provides a set of tools that assist in this process, such as Pull Request, comments, and even notifications regarding missing or recently added code.
1. The developer who wrote the code creates a pull request (PR) and lets the team know that the PR was created. (A Slack bot might be created to notify everyone that a PR was created).
2. Once the PR is created, someone else starts reviewing the code, in accordance with a guide providing rules, standards and processes. The guide suggests primitives to be nice to the person whose code is under revision: “Ask questions; don’t make demands”, “What do you think about naming this: user_id?”” or “Avoid using terms that could be seen as referring to personal traits. Assume everyone is attractive, intelligent, and well-meaning.”
3. After one or two developers have reviewed the code, one or both steps should be followed:
- The code needs improvement. Then, the developer could either start a discussion regarding the best way to solve the problem, or just follow the suggestions.
This step is repeated until all developers are involved and agree on the fact that the code is good enough. The iterations stop and the code can be merged back into the development branch.
- If the code is good enough it can be merged into the development branch.
Why is it important?
Being transparent and consistent with this process has made the company more robust and horizontal. Knowledge is shared, thus improving quality, by assuring the code meets a standard which results in much more reliable deliverables. Since we started implementing the process the impact has been tremendous.
Which is the result?
At the beginning, the productivity seems to be slowed down, but as code review grows and multiplies among the team members, productivity actually increases. Bugs are found sooner, more ideas, tips, and solutions are shared, and, therefore, the quality of the delivery gets better and better. Besides, as the whole team is involved in the process, everybody will get to know the code and the architecture in greater depth. This leads to more accurate solutions, more maintainable products, faster bug fixing, and feature development.
A win-win practice
As mentioned before, we are big fans of doing code review. We have learned that it is important for our team members and for our clients. Fewer bugs, faster feature development, shared knowledge and better and deeper involvement.
It is not just a practice, it is part of our DNA.
