What are code reviews: just the essentials ?
Code reviews, also known as peer reviews, are a process in which another person, or several other persons, have a look at your code and give suggestions for improvements and spot potential issues before they cause actual problems for real people.
Now, I feel obligated to mention that code reviews are only one of many tools used to keep errors out of your code. You also have static code analysis, unit tests, integration tests, user acceptance testing and many more variants. However, we will leave these for another time.
Table of Contents
How to do code reviews ?
There are many ways of getting another pair of eyes to look at your code. Anything that works for you and your team, should be the way to go. As a general rule, if the system you are trying to implement is easy to use, you will get faster onboarding from the people involved, and less push-back on the change.
That being said, there are a few canonical ways of doing code reviews.
- Pair programming: This involves working together with one of your colleagues on the task at hand. Usually each person switches between writing the code and checking the code.
- Email: I must admit that I never tried this method personally/ However I have heard about teams that are successfully doing reviews this way.
- Dedicated review tool: This is the usual way we do reviews. There are several options out there that you can pick from. Github pool request review tool, and Crucible, are some tools I played around with.
What do you gain by having code reviews ?
Well, the first advantage is the reduced number of issues that you have to fix later on, and that is no small feat. However, it doesn’t stop here.
When people know their code is getting looked at by someone else, they take more care when writing it. They spend more time thinking about the variable names and try to spot issues themselves, and by doing just that, the number of issues is reduced.
Another use for code reviews, is to spread knowledge on the project to the team. This only works if everyone on the team can see the code that is up for review. If you add everyone as the reviewer, then everyone is (ideally) up to date with the changes on the project.