Code review is widely seen as one of the most important practices to maintain code quality. It’s sometimes dreaded or intimidating, yet a multiplier of individual growth and knowledge distribution within the team.
The code reviewer can ease this process by letting us know in advance what are the things they’ll be looking for. Making the guidelines explicit and available beforehand helps both parties (reviewer and reviewee) as it minimises friction and communicates expectations clearly.
Here’s our checklist for a painless code review.
- Can we run the code?
- Are there any errors or warnings in the application output?
- Are the tests passing?
- Is the functionality matching the specs? For UI components, does the implementation reflect the design?
- Does the new code respect the existing architectural guidelines?
- Is a similar feature was already implemented, does the new code respect the same implementation model?
- Do new concepts follow the previous naming conventions? Are domain models referred to by the previous name, not synonyms or new names?
- Can we remove anything and get the same results?
- Can we extract anything and make it more reusable?
- Has the cyclomatic complexity increased? Why?