Code review — The Process for Developer and Reviewer

SaurabhG
2 min readApr 1, 2022

Hi Folks,

Since the start of software development , there are two poles who never likes to get along each other. The Developer who writes code while scratching his head down & The reviewer who reviews that code keeping heads up.

Jokes apart code review is an important which every developer should adhere to. it helps to promote the code which is enabled with best practices, aligned with business requirement & code flow etc.

Here I am sharing an article found over google which explains the code review process through pyramid.

https://www.morling.dev/images/code_review_pyramid.svg

The Pyramid identifies what aspects need focused manual reviews and what can be automated with tools to review and possibly fix them automatically.

The guideline also lists set of questions to be asked.

API Semantics:

• API as small as possible, as large as needed?
• Is there one way of doing one thing, not multiple ones?
• Is it consistent, does it follow the principle of least surprises?
• 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?

Implementation Semantics:

• Does it satisfy the original requirements?
• Is it logically correct?
• Is there no unnecessary complexity?
• Is it robust (no concurrency issues, proper error handling, etc.)?
• Is it performant?
• Is it secure (e.g. no SQL injections, etc.)
• Is it observable (e.g. metrics, logging, tracing, etc.)?
• Do newly added dependencies pull their weight? Is their license acceptable?

Documentation:

• New features reasonably documented?
• Are the relevant kinds of docs covered: README, API docs, user guide, reference docs, etc.?
• Are docs understandable, are there no significant typos and grammar mistakes?

Tests:

• Are all tests passing?
• Are new features reasonably tested?
• Are corner cases tested?
• Is it using unit tests where possible, integration tests where necessary?
• Are there tests for NFRs, e.g. performance?

Code Style:

  • Is the project’s formatting style applied?
    • Does it adhere to agreed on naming conventions
    • Is it DRY?
    • Is the code sufficiently “readable” (method lengths, etc.)

Thanks to Gunnar Morling for sharing great article on code review process.

Reference Links :

https://www.morling.dev/blog/the-code-review-pyramid

--

--

SaurabhG

I am an enthusiastic learner. Always want to challenge my last learning & keep hunting for new learning. about.me/saurabh.gangrade