If you read this post, you and I have one same thing. Code review process’s important, right? But how to make this process effective and meaningful?

Why you need to review another’s code

As developers, we want to build new great shiny features without bugs. Unfortunately, just like anything else, there’re no such thing in this world.

Code review is a development process that was created specifically to address this problem. Instead of aiming at the impossible goal of writing code without errors, with code reviews you can instead focus on catching these errors before they make their way to your users/customers. It brings a colleague (or a few) to cross-validate the work. Believe me, it’s much cheaper (money and effort) to fix bugs earlier.

Doing it effectively

So you know why we do it. Let’s talk about how to do it. Stages and questions should be asked at each stage

Implementation semantics:

• Does it satisfy the original requirements?
• Is it logically correct?
• Is it unnecessary complexity?
• Is it robust? (no concurrency issue, proper error handling, etc.)
• Is it performant?
• Is it observable? (log, tracing, metric, etc.)
• Do your shiny dependencies pull the weight? (Node JS trigger :D)

API semantics:

• API as small as possible or as large as needed?
• Are there no breaking changes that can break another behavior?
• Clean/split internal API and public one

Documentation:

• New feature reasonably documented?

Test:

• Are all tests passing?
• Are new feature reasonably tested?
• Are edge case tested?

Code style:

• Is the project’s code style applied?
• Is the code sufficiently “readable” (methods length, naming, etc.)

You should spend most of your effort to Implementation semantics, API semantics and Documentation. Test and Code style should be automated

DISCLAIMER: the opinions expressed within the content are solely the author’s and do not reflect the opinions and beliefs of any organization.