By Smitheo
Jan 08 2025
Code reviews are more than a technical formality—they're a cornerstone of building robust, scalable, and high-quality software. In this post, we explore how a well-structured code review process improves team collaboration, reduces errors, and enhances code maintainability. Learn actionable insights and best practices that will elevate your development workflow and deliver measurable value for your projects
Inspired by some of the last few projects, I have noticed that still a lot of people don't consider Code Review seriously.
From extreme cases where code review doesn't exist at all or where pull/merge requests are approved in a few seconds after being opened. In the cases where a minority of team members care and perform code reviews, and the rest of the team members ignore them. The funny thing is when they are explicitly asked to check it, they consider them as "punishment".
Luckily, one of my first projects had a really good code review process where all team members were very active and performed strict but fair code reviews. On that project, I learned a lot, learned why this process is so important, and gained really good habits on how to perform code reviews.
That's probably one of the reasons why I'm writing this today.
Recently I was preparing guidelines and best practices about code reviews so I decided to share them with you as well.
The things you will see here are not only my statements, they are inspired by other people, teams, and companies. But with those statements, I totally agree and I stand behind them.
A code review is a process where someone other than the author(s) of a piece of code examines that code. Code review should be used to maintain the quality of our code and products.
Once you're satisfied and proud with your implementation and the tests, you create a pull request. With a pull request, you are requesting the merge of your local branch into the main source branch.
All dev team members (including Leads / Architects) should be default reviewers of the pull request. The reviewer's job is to check if all requested functionalities are properly implemented and tested. She/He can suggest code improvements like using some library instead of reinventing the wheel, better naming for components and variables, and any other improvement that she/he can suggest.
It is important that you shouldn't be disappointed if you receive a lot of comments on your pull requests. You will learn from the feedback and the solution will be better.
When the minimum required number of reviewers have approved the pull request you can merge it. Don’t forget to delete your source (feature/bugfix) branch and move the ticket that is ready for QA (after it's deployed).
Goal: Learn, and improve your code quality, morale, and your working relationships.
Before sending code to your teammate, read it yourself and check the things that you would check as a code reviewer.
The recommendation is always to be up to date with the latest state from develop branch. This means that during the day you should pull changes several times and merge it to your local feature branch.
Before creating a pull request make sure that your feature/bugfix branch is up to date.
Try to make your pull request as small as possible.
Smaller pull requests:
Don’t take personally code review feedback. Treat your reviewer’s notes as an objective discussion about the code.
From time to time, reviewers are wrong. Just as you can accidentally write buggy code, your reviewer can misunderstand the correct code.
For every comment that requires action, respond explicitly to confirm that you’ve addressed it. Some code review tools allow you to mark comments as resolved. Otherwise, follow a simple convention, like, "Done", for each note. If you disagree with the note, politely explain why you declined to take action.
Don’t directly ask/chat with the reviewer about every comment. Commenting and discussing directly in the pull request is useful for other reviewers as well.
Once you create a pull request, driving the review to completion should be your highest priority. Delays on your end, will waste time for your reviewer, and increase complexity for your whole team.
In the case of:
schedule 1 on 1 call with the reviewer to resolve all doubts and unclear things. Make sure that you comment back on agreements directly in a pull request for other reviewers.
Goal: Mentor, educate, and improve your working relationships.
Code review is a chance for developers to mentor and teach others.
When you comment on someone's pull request:
Remember to praise good code and decisions. Don't only point out problems and suggestions.
Don’t ignore pull requests and think someone instead of you will do the review.
Make a habit of doing code reviews like in the morning before daily, around lunchtime, or before the end of the working day.
If you are in the middle of a focused task, such as writing code, don’t interrupt yourself to do a code review. Instead, wait for a breakpoint in your work before you respond to a request for review.
Your opinion is important and expected here as well. More experienced team members don't know everything and they also make mistakes.
The speed of individual development is important, but not as important as the speed of the entire team.
The speed of the team as a whole will be decreased if the individuals don’t respond to the pull requests, do the review, and push other work (task) in the done direction.
If you are not in the middle of a focused task, you should do a code review shortly after it comes in.
If you follow these guidelines and you are strict with your code reviews, you should find that the entire code review process tends to go faster and faster over time.
Developers will learn what is required for healthy code, and when you create a pull request that is great from the start, it will require less and less review time.
Reviewers will learn to respond quickly and not add unnecessary latency to the review process.
But don’t compromise on the code review standards or quality for an imagined improvement in velocity—it’s not actually going to make anything happen more quickly, in the long run.
Leverage best practices and tailored solutions to drive success. Contact us today to learn how we can help optimize your Adobe Experience Manager implementation.