Imagine: you open a colleague's pull request, you see 847 modified lines in 23 files, and the first thought is "where to start?". Sound familiar?
Code review is not just a formality before a merge, but the art of finding a balance between being picky and constructive. Let's figure out how to check someone else's code so that it benefits the entire team.
Why do you need a code review at all?
Many novice developers perceive reviews as a barrier to production. But in fact, it is a powerful tool that solves several problems at once. First, it catches bugs before they get to users — a second look always notices what the author missed. Secondly, it is an exchange of knowledge within the team: the junior learns from the senior, and the senior learns about new approaches from the junior. Thirdly, code review supports a unified code base style, which is critical for long-term project support.
Where to start the check?
The first rule of a good reviewer is to understand the context. Read the task description, look at the related issues or tickets in the tracker. Without understanding the "why", it is impossible to evaluate the "how". For example, if a developer has added caching that seems redundant, it may be a solution to a specific performance issue.
Start with the big picture, and then dive into the details. First, evaluate the architectural solutions: whether the approach is correct, whether the code violates the SOLID principles, whether the change corresponds to the overall structure of the project. Only then move on to the little things like naming variables or formatting. It's like evaluating a building: first we look at the foundation and load-bearing walls, and then at the color of the wallpaper.
What to look for?
Logic and correctness
The most important thing is that the code must work correctly. Check the boundary cases: what happens with an empty array, a zero value, or a negative number? Think about race conditions in asynchronous code, about memory leaks, about correct error handling. A good question to ask yourself: "What could go wrong?"
Readability and maintainability
Code is read much more often than it is written. If it takes you five minutes to understand what a 10-line function does, that's a problem. Variables should have clear names (not data, tmp or x, but userCredentials, temporaryBuffer, horizontalOffset), functions should do one thing, classes should not turn into "divine objects" of a thousand lines.
Performance
Common sense is important here. You don't need to optimize the code that runs once an hour when the configuration loads. But if you see an O(n²) algorithm in the handler of each HTTP request, this is a red flag. Pay attention to unnecessary database queries in loops (the classic N+1 problem), to excessive copying of large objects, to the lack of pagination where it is critical.
Safety
SQL injections, XSS attacks, and sensitive data disclosure can all slip through to production due to careless reviews. Check that all user data is validated and escaped, that secrets do not get into logs or repositories, and that authentication and authorization are configured correctly.
Tests
Good PR includes not only code, but also tests for it. Check that the new functionality is covered by tests, that the tests really check important scenarios, and not just call the function for a tick. And make sure that all tests pass — a green CI/CD pipeline is a must.
How to give feedback?
Comments in code review are not a place for personal criticism, but a platform for discussing code. Instead of saying, “You wrote a terrible function,” say, “This function is difficult to understand. Can you break it down into a few smaller ones?” Instead of "This is a stupid decision," say "Have you considered using the Strategy pattern? It can simplify the code." Always explain "why": not just "rename the variable", but "the name data does not give an understanding of what is in the variable. Maybe userSettings or apiResponse?"
Use prefixes in comments to show the importance of the comment. "[CRITICAL]" or "[BLOCKER]" for errors that cannot be merged, "[SUGGESTION]" for optional improvements, "[QUESTION]" when you want to understand the logic of the author. This helps the author prioritize and understand what needs to be fixed and what can be moved to a separate task.
Don't forget to praise good code! If you see an elegant solution or excellent refactoring, write about it. Positive feedback motivates no less than constructive criticism and creates a healthy atmosphere in the team.
How much time should be spent on a review?
It depends on the size of the changes, but there is one important rule: it is better to do reviews in small portions regularly than to check a giant PR once a week. Studies show that the effectiveness of reviews drops after 200-400 lines of code — the human brain simply gets tired. If the PR is too large, ask the developer to split it into several parts.
Don't put off the review until later. Ideally, check the code within a few hours after creating the PR — so the author still remembers the context, and the feedback brings maximum benefit. A blocked PR slows down the entire team.
Automation to the rescue
Modern tools take over routine checks, freeing you up for important decisions. Linters monitor code style and catch typical errors, static analyzers find potential bugs, CI/CD runs tests and checks the build. Set all this up in advance so that you don't waste time arguing about spaces and indents during the review.
SonarQube, ESLint, Pylint, RuboCop, SwiftLint — choose the tools for your stack and integrate them into the development process. Let the computer do what it does better than a human, and you focus on architecture, logic, and business requirements.
Typical mistakes of reviewers
Nitpicking. Do not write 15 comments about formatting if there are serious architectural problems. First the important, then the secondary.
Imposing your style. The fact that you always write loops through map does not mean that for is bad. If both options work and read normally, it's a matter of taste, not a mistake.
Insufficient depth of inspection. "LGTM" (Looks Good To Me) after a cursory review is a disservice. If you are going to review, do it well.
Aggressiveness and snobbery. Phrases like "any junior knows that they don't write like that" discourage the desire to develop. Be a mentor, not a judge.
Code review as a learning tool
For juniors, reviewing someone else's code is an opportunity to see different approaches to solving problems, learn new libraries and patterns. For seniors, it's a chance to pass on knowledge and grow a strong team. Use comments not only for criticism, but also for explanations: add a link to an article on the DRY principle, show an example of refactoring, explain why asynchrony is important here.
Some teams practice peer reviews or group discussions of complex PRs. This takes more time, but it gives a deeper understanding and aligns the level of knowledge in the team.
Code review culture
Ultimately, the effectiveness of a review depends not so much on technical skills as on the culture in the team. If developers take comments as personal criticism and get offended, if reviewers arrange a witch hunt for each PR, the process turns into a formality. But if the team sees the review as a tool for joint growth, where everyone learns and helps others, the code becomes better, and work becomes more pleasant.
Remember: the purpose of a code review is not to find the perfect solution (it often does not exist), but to make sure that the code works correctly, is understandable to the team and will not create problems in the future. Everything else is just details.
Appendix Code is your personal mentor in the world of programming. We have created courses specifically for beginner developers, where each topic is explained in simple language with lots of practice. From the basics of Python and JavaScript to working with Git, databases and creating real projects — you will go from the first line of code to a confident junior developer. Each lesson is structured so that you not only memorize the syntax, but also understand how to apply your knowledge in practice. And when you learn to write quality code yourself, you will know exactly what to look for when reviewing someone else's!
Join our Telegram channel!
We have a friendly community of developers where you can ask any question — from “why this cycle does not work” to “how to properly design the application architecture”. Every day we analyze the top topics in development, share useful materials, discuss industry news and help each other grow. There are no stupid questions here, only informative discussions and mutual assistance. Start your IT journey with Kodik — learning programming has never been so interesting!