I’m here to tell you about code review (or as some may know it peer review) is, where it came from and how to effectively implement code review, without removing the important factor of psychological safety, and also share my experiences along the way.
What is code review?
Code review is a system where your team members critically look at the code you wrote then give you feedback on things like readability, quality, or perhaps business cases that you could have missed in your code. Your peers either learn from what you have done or help you correct your code and find bugs you might have missed.
How reviews began and how it evolved into what we have now?
The initial reason for code review was to help the whole team take ownership of the software that was being created, so each person would personally have a hand in the quality of the software that was written.
So not so long ago, but what feels like ages ago, in the magical world of Software any updates were not as streamlines as we have today. This meant there was less room for error, so these systems were built with no room for error. We still have systems like this even in today's time, for example, the firmware in your toaster.
One of the ways they prevent errors from happening in these systems was by using a code review system. This is probably not the same as what you have in mind that we use these days, but rather a meeting room with developers that all have a printed version of your code critically evaluating every line. This I could only imagine would drive the project manager mad in these days with the tight deadlines we have in this strick ‘Agile’ world we live in today.
So as the magical world of programming that we live in today changed and evolved over time so did the Code review system. We got the magical pull request system added to our version control. This means that as part of our source control we can also review the code that goes into our code, this helps prevent the code from being contaminated with code smells.
Why code review is important?
We need code review to share knowledge on the features that are being worked on and to help your team catch bugs before the code even goes out to be tested. The team will also be able to learn of different ways to write code because one person might be using language functions that you didn’t even know existed for example. This especially helped more junior developers as they might have some fundamentals that they don’t understand yet.
When we do code reviews, the problem could be caught at the lowest point of invested time, and as they say, time is money. So having code reviews is like having a extra test environment without all the hardware costs in my opinion. The people doing the reviews might catch bugs the same as what would happen at a testing level, in the same breath I don’t think code reviews would ever replace testing environment.
So code reviews will be another quality assurance gate that your code has to pass through which would be evaluated at a lower level, so the code will be evaluated at a maintainability level as well.
Code reviews also allow you to enforce code standards of the team on the project you are working, creating a more readable codebase which could help future developers understand better as to what they are reading without too much effort, letting your code live on.
Code review tools
There are tons of amazing and free tools to use when you do code review, the best tool to use will mainly depend on the source control that you are using. Most of the source control providers have features where you can apply policies to branches that require you to make a pull request before you can merge your branch in and then allows you to specify how many reviewers are required to review your code before you can merge in your code.
My takebacks from using code review
I tend to write much better code if I know someone is going to review the code that I have written so just the fact that someone is going to look at ti helps already.
I find it much easier to collaborate with people even if they are off-site as I see what new features have been added and what they are working on meaning I don’t duplicate code.
I have learnt lots of good practices from looking at the code that the people around me write and I have gotten lots of constructive criticism.
It has added an extra safety net to development processes tending to keep me from committing that bug whack-a-mole code I wrote late at night.
Merge!
Thanks for taking the time to read my take on code reviews. Now I will leave you the same way I leave all my PR’s, with a wonderful puppy gif:
Top comments (0)