Member-only story
5 Rules for Every Code Review
Don’t just hit “Approve”
Code reviews are the glue of any effective software engineering team. A code review is the stage at which an engineer requests their changes to be merged into the main development branch. During a code review, other teammates and senior leadership can comment on and suggest changes to your code through version control systems such as Git and GitLab.
Code reviews are the inflection point from an individual engineer’s changes into a team-wide contribution towards a central code base.
The most important piece of code reviews lies within this transition. Code reviews start with individual ownership from one or two developers and end with team ownership. Once that code has been merged, any future bugs or problems are not an individual’s problem — they are a team problem.
In the age of fully remote technology teams, code reviews matter now more than ever. It’s extremely important to take the proper amount of time (bonus tip) to review a teammate’s code. A team that has effective code reviews gains the advantages of adhering to industry standards, onboarding new developers faster, and creating lasting software, just to name a few.
With all this being said, being competent in your code reviews is critical to becoming a proficient software engineer. If you’re like me and too often just hit “Approve,” then it’s time for us to get our act together and learn five rules for every code review!
1. Always Share Your Thoughts
As obvious as it sounds, you have to be critically aware of your thoughts when you’re participating in a code review. If you’re a newbie and don’t understand what the code is doing, you need to voice your confusion. In this situation, you may want to contact your teammates over your messaging system before commenting on the merge request.
However, I’ve also seen countless senior developers repeatedly ask for clarification. The solution could be as simple as adding a comment for some byte manipulation, or it could involve an entire refactoring of an algorithm. It…
