Our Top 10 Code Review Practices

Accesto has just turned 15. During this time, we have accumulated a couple of clients that worked with us for almost a decade. So I asked one of them a simple question: “Why have you stayed with us for so many years?”

The answer was short: quality.

One customer once told me our work was “surprisingly bug-free.” It sounded almost funny at the time, but “surprisingly bug-free” has become one of the best compliments we’ve ever received. Code and solution quality have been our number-one priority since 2010, long before it became a cliché on software company websites.

But where does that quality come from? There are many ingredients, but one stands above the rest: code review.

Code review must be a non-negotiable step of the development process. It should never be rushed, ignored or treated as a checkbox. Yet over the past few years, we’ve heard more and more teams say they skip code reviews because they “take too much time” or “only catch indentation issues.”

Those people couldn’t be more wrong.

If your code reviews focus on commas and formatting, then yes — you are wasting time. But when done correctly, code review becomes a game-changer for product quality, developer satisfaction, and long-term project cost.

To mark our 15 years in business, we distilled everything we’ve learned into 10 practical, easy-to-apply rules. These are the habits that have shaped our engineering culture — and we hope they will help you raise the bar for your own team.

10 Key Ingredients of a Great Code Review

1. Start With a Self-Review

First step in any good Code Review is the Self-Review. Before sending code for peer review, developers should first review it themselves. Creating a pull request and reading your own changes with a reviewer’s mindset — detached from the “I just wrote this” perspective — is incredibly effective. It exposes small mistakes, leftover debug code, or pieces you meant to clean up but forgot.

A quick self-review reduces unnecessary back-and-forth and avoids frustrating the person on the other side of the pull request.

Source: No PHPun Intended.

2. Never Review What Can Be Automated

A human should not spend time checking what a tool can check better.

Formatting, styling, and many repeatable rules can now be handled automatically. For PHP, tools like PHP CS Fixer or PHPStan eliminate entire categories of manual review work.

Your reviewers’ time is valuable — don’t waste it.

3. Review the Solution, Not Just the Code

Perfect code is worthless if the solution doesn’t work.

That’s why at Accesto, reviewers usually launch and run the code. It gives a better perspective on the implementation, helps catch bugs and errors earlier and reduces surprises during acceptance testing.

If setting up the environment on the reviewer’s machine will take too much time or effort, have the author walk you through the working solution on their own machine.

4. Use Proper Branching to Keep Reviews Focused

We rely heavily on the Boy Scout Rule: always leave the code cleaner than you found it. I believe — many do.

Essentially, whenever a developer works on a feature, the surroundings can also be a little bit improved and cleaned up. Sometimes it may lead to more changes in the code than the primary implementation intended. Renamings, especially, can lead to modifications in many files.

In that case, it is advisable to separate this refactoring from the task's essence and submit it in a separate pull request. So that a person reviewing the pull request can focus on what’s important. Otherwise, the main task may be lost among refactoring work, and not enough time will be spent on reviewing what's important.

5. Promote Technical Theory, Not Just Practice

In interviews, I always ask about theoretical foundations like the SOLID principles or design patterns.

Some developers claim theory doesn’t matter as long as they “know how to code.” But in a code review, theory becomes a shared language. Instead of writing long explanations, a reviewer can simply point to a violated principle or propose a well-known pattern.

Without that shared vocabulary, every discussion takes longer — and often ends in misunderstandings.

6. Sometimes It’s Better to Talk Than Type

Not every code review needs to be conducted within a tool.

For complex features, it can be far more efficient to jump on a call or meet in person. Ask questions, understand the rationale and walk through the implementation together.

Remember: the Agile Manifesto values individuals and interactions over processes and tools.

Choose the review method that fits the change — not the other way around.

7. Don’t Rely Solely on Notifications — Communicate

Git platforms send emails and notifications, but they’re easy to miss.

If you’re waiting on a review, speak to the reviewer directly. You’ll also have a chance to communicate if it’s important or urgent. This simple habit prevents unnecessary delays and keeps development flowing.

8. Avoid Review Bottlenecks

If only one person can perform reviews, the entire team becomes blocked.

This usually happens when a tech lead or senior developer tries to review everything. It might sound efficient as that person is the most knowledgeable, but really only works on small projects; otherwise, it quickly becomes a bottleneck.

So my suggestion is to avoid such situations beforehand, distribute review responsibility.

9. Don’t Allow Too Many Open Pull Requests

The more open reviews you have, the more things get lost. Diverging branches become harder to merge, context gets forgotten, and small issues snowball.

Review quickly, merge quickly.

This is often cited as a weakness of Git Flow, and while trunk-based development helps, you can still make Git Flow work if your team prioritizes timely reviews and merges.

10. Measure Your Process — and Make It Fun

To improve your code review process, you first need to measure: number of open pull requests

• average time spent in review
• number of comments
• reviews with zero comments

And so on.

Metrics give you visibility — and can also create friendly competition.

At Accesto, we turn code review stats into a small annual contest. Awards for the most reviews, most insightful comments, or highest average engagement always add a bit of fun to the year’s end.

Conclusion

Code review done poorly — wastes time.

Code review done well — safeguards quality, prevents bugs, accelerates development, and protects your team from the hidden costs of technical debt.

For us, it has been a cornerstone of our work for the past 15 years — and one of the reasons our clients stay with us for so long.

If you want better code, fewer bugs, and a happier development team, start with code review. But do it right.