How we review pull requests

Give context

As the author of a pull request, it is crucial to provide context since you have a deeper understanding of the changes, while the reviewer does not.

Although not all pull requests require extensive context, it can be beneficial. Sometimes a simple screenshot or short video can go a long way in helping the reviewer understand the changes.

We ensure the pull request title is clear and provides a good description of what the pull request accomplishes. Highlight specific areas where we need feedback and include links to related documentation, issues, or other pull requests for additional context.

One change at a time

Each pull request should be focused on a small and specific task.

This approach minimizes context switching, making it easier for the reviewer to scan and review the changes.

If multiple changes are necessary for different improvements, we separate them into individual pull requests. This reduces confusion and the risk of introducing bugs or regressions, as the reviewer can concentrate on one thing at a time.

Responsibility

Taking responsibility for the code we approve is essential. If a change causes a bug after deployment, it is partly the reviewer's responsibility.

Code reviews are a core part of our job, not a distraction. When we provide feedback, we don't just point out issues; we explain why an alternative solution might be better. For instance, instead of saying, “We shouldn't use this approach” we suggest, “Here's another way that could be better because of X and Y.”

Understanding the code being changed is vital; if we don't understand it, we can't effectively review it.

To avoid excessive back-and-forth in pull request comments, we usually use Slack DMs or huddle to have better discussions when needed.

Tools

Our CI/CD integration ensures that dependency checks, linting, formatting, building, and testing are automated. Additionally, deploying preview apps can provide better context and facilitate more effective testing.