Kontextbezogenes Code-Review

Contextual Code Review

Reading only the green and red lines of a diff misses the most dangerous bugs. A change is safe only in the context of its callers, dependencies, data contracts, and runtime environment (Michael Feathers & Michael Fagan).

Thinking Sequence for Every Review

1. What must this change achieve?
2. What is the accepted scope and expected behavior?
3. Where does the code implement it?
4. What happens on the main path, error paths, and boundary cases?
5. What does it alter in existing system behavior?
6. Which claims are backed by real checks?
7. Is there a concrete, actionable defect that requires a fix?

Workflow

1. Expand context beyond the modified lines:
   • Inspect all callers of any modified function, hook, component, or endpoint to verify their assumptions about arguments, return values, nullability, and thrown errors still hold.
   • Inspect all callees and existing guards (upstream middleware, schema validators, database constraints, transactions) before claiming a check is missing.
2. Trace control flow and data transformations end to end:
   • Follow data from entry point (HTTP request, CLI arg, UI event, queue payload) through validation, domain logic, persistence, and response serialization.
   • Check for off-by-one errors, inverted boolean conditions, unhandled null/undefined, mutated shared references, unawaited promises, and resource leaks.
3. Separate new regressions from pre-existing technical debt:
   • Introduced or worsened by this change: In scope for blocking or targeted review findings.
   • Pre-existing issue in untouched code: Only flag if the current change directly triggers or amplifies it, and explicitly label it as pre-existing rather than blaming the diff.
4. Calibrate review depth to risk:
   • Spend deep analytical effort on state transitions, permissions, financial/usage math, migrations, and public contracts; never pad a review with subjective naming or formatting nitpicks.