A Pyramid of Concerns for Code Review
I once interviewed a software engineer for a role at a company and this was how they explained their approach to code review.
Pyramid of concerns from abstract to concrete. Each layer builds on the previous one and acts as a check of it.
- Big picture
- What is the motivation for this change? Why are we doing this?
- How does this fit into the wider product and codebase? Is this iterable?
- Is this a complete ‘story’ of work?
- Solution architecture
- How does the problem decompose?
- Does the solution fit the problem?
- What are the trade-offs, compromises, and assumptions?
- Testability
- Can I poke the fns and play with the code and see what it does?
- Might not have tests now, but does the code lend itself well to automated testing?
- Comprehension
- Are vars and fns named appropriately?
- Can I read this and grok it?
- Is this idiomatic to the language and the codebase?