Code Review

Introduction

We use pull requests to document code reviews. Each pull request description should contain key information about the change, as well as any relevant details. At a minimum, code reviews should be performed by someone capable of understanding the change and its associated risks.

Considerations

When approving a pull request, we consider several important factors:

• The change must be secure to address any security concerns.

• It needs to be maintainable, ensuring long-term quality and stability.

• If manual testing is required, it must be performed to verify the change.

Code review anti-patterns

A common anti-pattern when using pull requests is waiting too long for reviews. Ideally, the lead time for review should approach zero. Delays in integration can lead to larger and larger changes being batched together. This results in larger pull requests, more delays, poorer code reviews, and ultimately more risks.

Our team uses pair—or ensemble programming, a practice where more than one person works together to complete tasks. This way, as soon as one developer creates the pull request, another person can sign off immediately.

Info The reviewer should not be the person who pushes the last commit on the branch.

Implementation of this control

• Real-time reviews with pair or ensemble programming are preferred.

• Pull requests are used to document reviews in Bitbucket.

• The main branch in each repository is protected.

• Pull requests are recorded, ensuring that no runtime workload is missing PR attestations.