code-review-pyramidlisted

# Code Review Pyramid The Code Review Pyramid provides guidance on aspects to focus on during code reviews, prioritized by the cost of fixing issues later. Layers at the bottom of the pyramid deserve more attention because they are harder and more expensive to change after. Layers at the top are easier to address (often automatable) and warrant proportionally less manual review effort. *Adapted from the [Code Review Pyramid](https://www.morling.dev/blog/the-code-review-pyramid/) by [Gunnar Morling](https://www.morling.dev/), licensed under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/).* ## The Pyramid Five layers, numbered from the base up. Manual review attention should be highest at the base and taper toward the apex, where checks should be automated as much as possible: 1. **API Semantics** — base: focus here most 2. **Implementation Semantics** — focus here 3. **Documentation** 4. **Tests** — automate where possible 5. **Code Style** — apex: automate ## Layer 1 — API Semantics Questions to ask: - API as small as possible, as large as needed? - Is there one way of doing one thing, not multiple? - Is it consistent? Does it follow the principle of least surprise? - Clean split of API/internals, without internals leaking in the API? - Are there no breaking changes to user-facing parts (API classes, configuration, metrics, log formats, etc.)? - Is a new API generally useful and not overly specific? ## Layer 2 — Implementation Semantics Questions to a