LEARN. PRACTICE. GROW.Prepare a change that can be reviewed
A fictional valuation service needs a rounding rule. The request also moves hundreds of lines and changes configuration enabling the rule. Before discussing approval, separate the questions: does the move preserve behavior, does the rule satisfy its requirement, and does activation find available code? A useful split follows these decisions. Cutting the diff every hundred lines may leave each part incomprehensible. Retain related tests with the behavior they demonstrate; a change with fewer lines but without its counterexample can be harder to assess. Prepare a description identifying the expected outcome and the example that failed previously. If the requirement specifies rounding per row, a matching total is insufficient. The reviewer should connect requirement, change, and outcome without depending on a private conversation with the author. A generated diff still requires attention to any changed generator assumptions.
Analyze intermediate states
In the local exercise, A adds a function, B starts calling it, and C enables that path. A, B, C respects the declared dependencies. B before A leaves a call without its function; C before B enables a nonexistent path. The model explicitly assumes all remaining requirements are satisfied. It neither compiles applications nor discovers hidden dependencies. In practice, ask the team to describe the state after each integration, including configuration channels that may advance faster than code. Two reviewers can discuss interface and consumer simultaneously if they share context. That simultaneity does not remove the required integration order. A reversion proposal also deserves its own analysis: undoing A while B remains can recreate the invalid call. The useful result is a sequence with observable prerequisites, rather than three cards simply moved to done.
Close gaps, not just comments
A reply saying “done” does not identify what was corrected. For a report that omitted its last row, request the change and an example distinguishing defect from correction. If the test failed twice and passed on its third run without edits, record the inconsistency; the third result does not explain the earlier ones. Investigation may find a product, environment, or test defect. Meanwhile, the conclusion should identify uncertain coverage. When a reviewer knows the functional flow but cannot assess a cryptographic implementation, retain the useful scope and obtain the missing specialty. Commercial pressure does not convert product familiarity into competence across all areas. If an important explanation exists only in review chat, make it accessible beside the code or appropriate documentation for the next reader. Any later modification requires consideration of its effect on earlier evidence.
Local practice and international handover
Copy the complete code below into technical-review.py and run python3 technical-review.py. No external packages are needed. Its twelve checks use invented data: six sequences, one queue, three effort calculations, and two queries over declared fields. Predict results before execution. The queue receives six requests and completes four daily; after five days it retains ten. This calculation measures neither individual productivity nor actual review duration. Try changing a dependency and explain the failure before changing the assertion. Then write an English handover for the next shift: assessed revision, covered behavior, later change, gap, owner, and next contact point. Compare “approved” with “calculation reviewed at R7; concurrency pending”. The second wording allows work to continue without inventing completion. The human handover and review of an actual repository have not been performed as part of this material.
"""Original teaching fixtures. No repository, identity, network or approval is inspected."""
import hashlib
import json
from fractions import Fraction
from pathlib import Path
import platform
checks = []
def check(name, actual, expected):
assert actual == expected, (name, actual, expected)
checks.append(dict(name=name, actual=actual, expected=expected, passed=True))
def sequence_ok(order, dependencies):
# Closed fixture: every declared step must appear once, no unknown steps.
if len(order)!= len(dependencies) or set(order)!= set(dependencies):
return False
done = set
for step in order:
if not set(dependencies[step]).issubset(done):
return False
done.add(step)
return True
steps = {'A': [], 'B': ['A'], 'C': ['B']}
check('declared_sequence_valid', sequence_ok(['A', 'B', 'C'], steps), True)
check('caller_before_function', sequence_ok(['B', 'A', 'C'], steps), False)
check('activation_before_caller', sequence_ok(['A', 'C', 'B'], steps), False)
check('missing_step_rejected', sequence_ok(['A', 'B'], steps), False)
check('duplicate_step_rejected', sequence_ok(['A', 'A', 'C'], steps), False)
check('unknown_step_rejected', sequence_ok(['A', 'B', 'D'], steps), False)
backlog = 0
balances = []
for day in range(5):
backlog = max(0, backlog + 6 - 4)
balances.append(backlog)
check('fixed_review_queue', balances, [2, 4, 6, 8, 10])
effort = 24 + 12
check('effort_break_even_weeks', str(Fraction(effort, 5)), '36/5')
check('effort_sensitivity_weeks', [str(Fraction(effort, x)) for x in (6, 3)], ['6', '12'])
check('reserved_capacity_weeks', str(Fraction(effort, 6)), '6')
# Declared fields alone are not observed competence or authorization.
people = [dict(name='Ana', available=False, areas=['module', 'access']),
dict(name='Rui', available=True, areas=['module'])]
def declared_candidates(area):
return [p['name'] for p in people if p['available'] and area in p['areas']]
check('declared_module_candidate', declared_candidates('module'), ['Rui'])
check('declared_access_gap', declared_candidates('access'), [])
print(json.dumps(dict(groups=len(checks), checks=checks, python=platform.python_version,
scope='Synthetic dependency, queue, effort and declared-field models. No network, actual code review, competence verification or approval.',
scriptSha256=hashlib.sha256(Path(__file__).read_bytes).hexdigest), ensure_ascii=False, indent=2))R4 covered valid inputs; R5 changes rejection of invalid inputs. Reuse what remains applicable and explicitly identify missing analysis.
Common pitfalls
Splitting by line count; separating related tests; approving an unassessed delta; using one green test to explain earlier failures.
Related topics: Continuous integration · Knowledge handover
Useful review connects a requirement to a change and obtained evidence while keeping unassessed areas visible.
Reference: Small CLs · Google Engineering Practices, SRE and DORA; Microsoft architecture decision and collaboration guidance; OWASP threat modeling; UK lead developer framework; inspected 2026-10-01