In my previous article Why Code Reviews?, I addressed the necessity of employing code reviews in the software development cycle. If I may quote myself, “starting with the code reviews would not instantly bring you all the benefits listed above. As with any process, code review should be implemented properly and improved constantly.”
As in the case of any other process, every team has to perfect and shape the processes to find what works best for them, but here are some guidelines that can be a good starting point. Note that this article does not cover the code review itself, meaning what should be checked when reviewing the code. Instead, it focuses on incorporating code review into your development cycle.
It is common to head out in the wrong direction when working on a big task or to find out that you have misinterpreted requirements while almost done with the task. One of the great ways to avoid the problems above is to send pull requests daily. It is one thing to redo one day of work, and it is another story when you are redoing two weeks’ worth of work. You don’t have to send anything polished; mark your pull request as “Work In Progress.” Keep in mind that the approach will be efficient only when the reviews are also conducted daily.
Keep in mind that although a short-term gain from code reviews is the discovery of programming errors, learning and mentoring are the most important long-term benefits. For that to happen, always provide reasoning for your comments, and put time and effort into explaining why you think there is a better way of writing the code. Bring a real-life example of what kind of problems the code may cause and how your suggested solution is helping to avoid those problems. Only explaining will guarantee that the reviews will result in knowledge after a while. Provide constructive feedback, not criticisms.
This goes hand in hand with the previous one. While getting reviewed, make sure you always understand why you are asked to change the code. Always be bold to ask questions or engage in constructive discussion if your reviewer needs to catch up on something. Understanding the comments will allow you to avoid similar comments in the future, resulting in less friction and better quality.
One of the essential things for spreading knowledge in the team is applying the review process throughout the team. This can often be tricky. Sometimes you can face a situation where only one experienced person can conduct the reviews. In cases like this, your team can switch 1+1 reviews by pairing inexperienced teammates with experienced ones when conducting reviews. After a while, you’ll have enough shared knowledge, allowing all the team members to run reviews independently. After that, your team can transition to one reviewer or stay with two reviews if it fits the team better.
Discussing tasks before starting the actual implementation usually provides excellent results. Not all the tasks will require a prior discussion. Still, preliminary discussion can save you a lot of time when dealing with tasks with complicated requirements, tasks requiring orchestration between different teams, or tasks requiring extensive knowledge of an existing code.
And finally. Come up with your checklist and use it whenever you send a pull request or review someone else’s code. Here is an elementary example of a checklist
Whenever you receive a comment, consider whether it can be categorized and incorporated into your checklist.
As I have mentioned at the beginning of the article, there is no magical recipe to fit all the teams, and indeed, every team should thoroughly examine and polish the processes to make sure it meets their needs. Still, having these guidelines as a starting point should give you a good start.
CEO at AOByte
Interested in the insurance software development solutions AOByte provides?
Send us a message, and we will get back to you to discuss your goals and project scope.
Input your search keywords and press Enter.
