At reinteractive, all code changes are reviewed by one or more developers before being released. This is done for every single line of code written. While there is the obvious benefit of having more eyeballs on that piece of code to ensure less bugs slip through the cracks, there are other benefits too!
Higher Code Quality
When you know your teammates will be looking through your code, it helps ensure you are focused on writing clear and concise code. Even if tiny errors in code or patterns slip through the cracks, your teammates can help you catch them before they get deployed and tested, thus helping reduce the number of bugs as well as making sure the code quality remains high. One way you can make it easier for your team to spot edge cases where you have to deviate, is to add comments to highlight why you deviated. It also helps to mention this in the description when making a pull request. That way your teammates don’t have to verify if you’ve done the deviation on purpose or if it was a mistake.
Increase Consistency
Code reviews help team members be across multiple codebases in dribs and drabs, while still working on a primary project. That means if a team member is away on leave or sick, it’s easier to get up to speed with their project to help with a bug fix or feature release, as you’ve been looking at parts of their codebase already.
Knowledge Sharing
Code reviews are a great way to share knowledge within the team—both as a reviewer, and as someone submitting the code for review. As a reviewer you get to learn how your teammates think and the patterns they tend to use. You also get a chance to ask why certain things are done in a certain way—whether it is a stylistic choice, or an unknown pattern. As someone submitting code for review, you get to learn alternative patterns, and tips from your team mates. This also means coding styles and patterns are more or less common across the team, and codebases tend to look more similar than not.
Onboarding
Knowledge-sharing code reviews also help a new team member get onboard faster, as they’re gaining knowledge from multiple team members at the same time by being asked questions and also receiving comments and feedback about their work.
Time Saved
Some may argue code reviews take time away from “actual development”. But the reality is, not having code reviews means the code could result in more bugs and inconsistencies, which are only found in production. This means bugs have to be reported, triaged, and old code re-read to figure out what the issues were. Or another developer looking at your code takes longer to figure out what’s going on as it could be inconsistent, and they’re not familiar with the codebase, etc.
If you aren’t already doing code reviews, give them a go. You may find your team shares knowledge better, finds more bugs earlier on, and has a higher quality output overall.
