Lisa’s team practiced pair programming, with the pair sometimes being a programmer and a tester. This is a great way to get two sets of eyes on the code and the tests and get immediate feedback on any problems. Even so, the team felt an additional review was a good idea. A more formal “code review” can be a good way to keep a record of changes. Even when teams engage in pairing or ensembling on code changes, extra eyes on the production and test code is a good thing.
Each developer pair on Lisa’s team created a branch from the code base trunk when they started a story. Typically, they finished a story within one or two days, which included all the testing and automation. At that time, they created a pull request. The product owner, who was also a senior developer on the team, was supposed to review the production and test code changes for that story and merge the changes into the trunk or main branch of the code base.
However, the team had a problem. The product owner was a huge bottleneck. He was overly busy and often could not even look at the pull requests for days. This was a big blocker for the team. After a retrospective focused on this problem, the team decided to enable more people to merge pull requests. The team’s testers were included in those empowered to review code and merge changes.
Thus, with the help of teammates, Lisa learned how to do code reviews in GitHub. She found this tool-based code review process helpful, so she continued to participate in reviews on subsequent teams. She found it was a quick way to see what was changed in both the production code and test coverage.
Below is a picture of a pull request in Github.
Benefits of getting involved
A healthy code review process is a big part of making code readable, testable, operable, and maintainable. They can help the whole team build shared understanding of their codebase, and they promote knowledge sharing. It’s also an activity where testers can add a huge amount of value.
Some of you readers may be groaning now about your own team’s code review process. Maybe you are thinking, “Ugh, the pull (aka merge) requests (a proposal of code changes to be reviewed and merged) are such a bottleneck for us!” or “The pull requests are so big, that I can’t begin to understand them, and I don’t have time to look.” Or perhaps you’ve never been involved with the code review process. It’s even possible your team doesn’t have a review process.
Some teams gather team members together to review code together. Others use a tool-based review process like Lisa’s team did. Either way, participating in code reviews benefits you, and your involvement will benefit your team. Code reviews are – or should be – a conversation. They’re more effective when the conversation includes people with diverse perspectives. It’s especially important for testing specialists to help review the code changes as well as the tests that support the code.
Another way to do reviews that Janet prefers is a peer review. Sit with the programmer and have them walk through their code with the reviewer asking questions. The reviewer can be anyone who knows the team’s coding standards. The idea of “articulating out loud” comes into play, and most programmers will find their own mistakes. It’s simple and effective – especially for non-critical systems.
A good resource for learning more about code reviews is a new book, Looks Good to Me: Constructive code reviews, by Adrianne Braganza. Code reviews are a great opportunity to collaborate with your team members and learn more about your team’s code. If your team isn’t doing code reviews, or if you do code reviews and they’re a source of annoyance, this book will help you have good conversations about how to improve the process.
AI-assisted code reviews
We all have feelings about AI and all the hype around it. The good news is that leading practitioners, as well as research done by organizations such as Google's DORA, show that AI tools can help with the speed, consistency, quality, and scalability of code reviews. Adrianne's book, mentioned above, has excellent guidance to help you get the benefit and avoid the pitfalls in Chapter 13. As she notes, AI won't take over code reviews, but AI-human collaboration can improve them.
We like how our friend Jen Cook, a leading quality practitioner, keeps it real:
- AI is a huge benefit in code reviews - it catches a ton of the basic 'duh' stuff, including nitpicky stuff a single human might slip by. That said, AI code review is no replacement for human code review, it's a complimentary practice.
There are many resources out there on AI-assisted code review, including this post from Angie Jones: https://angiejones.tech/how-i-taught-github-copilot-code-review-to-think-like-a-maintainer/
Contributing to your team's code review process is a great opportunity to improve your skills and help your team prevent bugs and deliver higher quality code.