Code reviews are a crucial part of writing a great software. They help to maintain code quality, catch bugs early, improve mentorship and collaboration withing the team. But if done poorly, they can be frustrating, time-consuming, and even demotivating, what could lead to the situation when they are not done at all, which is the worst case scenario.
First thing to consider is to keep pull requests smaller as the code review in this case will be faster and more effective. We should break big changes into smaller and focused updates.
Make Sure the Code Solves the Right Problem
What we need to do when accessing the code review is to confirm that the implementation matches the given requirements. Solving wrong problem is not of help here. Same goes with not solving the problem in the right way. Take the time to understand the code before commenting and avoid approvals without actually checking the details. LGTM comments are not useful in most cases except if the change is one line or too obvious.
If there are UI changes, we need to make sure they align with design specifications, and that application visually does not look weird or with design break.
Code Quality and Performance
Then, we need to be sure that code follows best practices and styling guidelines. There are plenty of tools (depending on the language) that can help to ensure styling guidelines are respected and they can be hooked inside the CI pipeline when the pull request is raised. It does not make sense to do these things manually when they can be automated. Next thing to consider is that best practices are in place, if the feature is easily extensible, if it follows existing code structure, etc.
Performance is another thing we should pay attention to, if we see that something could be done in different way to make the code execution faster, to avoid unnecessary complexity, etc. Here we should also pay attention to database queries, if they are written in a good way, especially when some ORM is used because often it hides additional complexity on queries which are executed on the database level.
Security and Testing
Next, we need to make sure that newly written piece of code will not have any security leak. This usually means to pay attention on potential risks of SQL injection, XSS, hardcoded secrets, missing input validations on both client and server side, etc.
Look for unit tests and integration tests where needed. Good practice here is also to have them included in CI pipeline, so the tests are already run and passed before you take a look at the code. Pay attention on the edge cases and possible failure points.
Give Constructive, Respectful Feedback
One of the most important things is the way how the feedback is given. This is sometimes crucial point and it reflects overall team culture. We need to focus on helping and not to be there as a judge who will just point on mistakes. Offering suggestions is way much better than focus on criticism. If critique needs to be given, criticize the code and not the developer. In the end, we need to know that everyone is making mistakes, no matter how experienced.
Good practice here is to first praise on what is done well, and then slightly change the direction to the areas that would need some improvement. With this approach, other person is feeling appreciated without finger pointing on the mistakes. After all, code is responsibility of the entire team together. In the same time, this is very good way for the older colleagues to practice mentorship.
Another thing to pay attention to is that suggestions are practical and easy to follow and in the same time that they avoid unnecessary refactoring unless it truly improves the code. Code reviews which are going back and forth just for the reviewer to be happy although it does not bring any real value should be avoided because it can lead to frustration on the other side. Other aspect is that then code review takes more time than needed and team is unnecessary loosing its speed.
Final Thoughts
Code reviews should be a positive and collaborative process. They are not just about finding mistakes but making the code better and helping each other to grow as developers. Keeping feedback constructive, focusing on maintainability, and using automation where you can will make the process smoother. Most importantly, we should remember that you are all on the same team, and that you are improving your product together.
Top comments (1)
Solid breakdown 👏. Love how you covered both the do’s and don’ts.
Code reviews aren’t just about catching bugs—they’re about building a culture of learning and collaboration. Small, respectful, and timely reviews go a long way