Code review: ownership, change size and infrastructure evidence
Choose reviewers by risk and ownership, split infrastructure changes into coherent units and attach evidence that can change an approval decision. Explain emergency review without permanent bypasses.
TL;DR: A review should give someone with relevant ownership enough context and evidence to reject an unsafe change. Keep each change coherent, make behavior and recovery explicit, and require the right approval through repository policy.
Ownership is a responsibility, not a notification
A code-owner file can route review requests, while branch or ruleset policy determines whether approval is required. Verify the actual enforcement. An automatically requested reviewer who can be bypassed by any contributor does not establish the control an architecture diagram might imply.
Assign ownership around the system being changed. A networking module may need both infrastructure and security review when it changes exposure. Sending every change to a central team creates a queue without guaranteeing domain expertise. Give routine changes a documented path and reserve additional approval for specific risk.
GitHub's code-owner documentation describes matching and enforcement interactions. Protect the ownership configuration itself: a contributor changing the review policy and the sensitive code in one request presents an obvious policy-design test.
A small change must still be complete
Size matters because the reviewer has to understand interactions. A ten-line security-policy diff can be harder than a hundred mechanical renames. Split by independently understandable behavior and deployable state, not by an arbitrary line limit.
Google's small-change guidance emphasizes focused review units. Apply that idea to infrastructure carefully: half of a migration may compile while leaving production in an incompatible state. Sequence changes so every intermediate version is valid.
Worked review: splitting a database credential change
Consider a pull request that replaces static database credentials, changes application connection pooling and upgrades the database driver. A reviewer sees three possible explanations for any later connection failure. The rollout also risks making old application instances unable to authenticate.
Split the work into compatible steps. First add support for obtaining the new credential while retaining the current path under an explicit configuration choice. Test rotation and connection replacement. Then change the deployment configuration for a small cohort, observe authentication failures and connection counts, and remove the old path only after the compatibility window closes.
The driver upgrade can usually proceed independently unless it is a prerequisite for the new authentication method. If it is required, explain that dependency and isolate unrelated cleanup. Reviewers need the reason for coupling, not a demand that all changes be tiny.
Attach a plan or diff for the actual target environment, a sanitized test result for rotation, and the failure signal that stops rollout. A screenshot of a green CI badge is insufficient if the tests never exercise credential replacement.
| Review evidence | Decision it supports | Weak substitute |
|---|---|---|
| Intended behavior and affected scope | Is the change necessary and bounded? | Restating changed filenames |
| Target-environment plan | Are creates, replacements and permissions expected? | A plan from a different workspace |
| Failure-path test | Does recovery work under the relevant fault? | Happy-path test alone |
| Compatibility and rollout notes | Can mixed versions operate? | “Rollback available” without conditions |
| Owner approval enforced by policy | Was required expertise involved? | Reviewer mentioned in a comment |
Keep review queues observable
Measure waiting time separately from active review and author rework. If a shared module has one overloaded owner, adding more reminder notifications does not create capacity. Train another qualified owner, document recurring review questions and make routine policy checks deterministic.
Avoid judging reviewers by comment count. A high-value review can identify one destructive replacement; a noisy review can add dozens of style comments already covered by formatting tools. AI code review can assist evidence discovery, but a generated approval should not impersonate the responsible human owner.
An emergency procedure may narrow review under an incident commander or designated approver. Record the concrete exception, the person accepting it and the post-change review obligation. A permanently available unlogged bypass will eventually become the default path for ordinary work.
Explain the decision
Should a 700-line pull request always be rejected? No. Inspect whether it contains one coherent change and whether generated output is separated from authored logic. Ask for a split when independent behavior or recovery paths are mixed.
Does CODEOWNERS guarantee approval? Only when the relevant repository rules enforce the required review and cannot be casually bypassed. Inspect policy and test a representative change.
When describing review improvements in an interview, connect them to actual evidence through project narratives, such as a documented reduction in review waiting time, rather than inventing a universal productivity percentage.