How to handle code reviews.
One of my Scrum Masters asked me this question:
Can we skip code reviews? It’s too expensive.
The concern was that it was taking too long for a reviewer to get back to the review requester. The Scrum Master then wanted to scrap code reviews so that code could be more quickly tested by the testers, without having to wait for the review.
This was my response:
Hi <name withheld> and all, We should ask ourselves what’s the purpose of having code reviews and to work to that purpose. Yes, there is a cost to code reviews, however the value can far exceed the cost! Please read and let me know your thoughts: https://smartbear.com/learn/code-review/agile-code-review-process/ There are a few options here for making our code reviews more effective based on what I understand thus far: 1. Just grab someone from the other team to do a code review. 2. Set up a peer (1 to 1) meeting to do a code review. 3. Batch up code reviews and make it a whole team affair at the end of each day (or some other appropriate timing). There are many benefits to code reviews: Short term: 1. Catch bugs early. It’s much cheaper to fix them before release (or when testing) then it is once its out in the field. 2. Ensure consistency of code. Part of a good code review includes stylistic review for code consistency. 3. Is reflective for the author of the code as they explain it to a reviewer (are we doing that or just tossing code over the wall?). Many times through the process of ‘talking’ about something, we deepen our learning and understanding. Long term: 1. Disseminates information across persons and teams. 2. Increases individual and team competencies in coding and domain areas. 3. Provides repeating opportunities to be reflective (see #3) above. Think of the code review as a coding retro. Every time we do it, it’s an opportunity to improve. Tze
Code reviews when done well is social a social experience, not merely throwing code over the wall and ticking a checkbox.