This post is a collection of mine and other people’s thoughts on code reviews. Only recently, having moved to a new team where code reviews were either not done well or not done at all, have I started to see all of their value beyond improving an individual’s programming ability. For teams working with legacy code, companies with high turnover, or where a sense of ownership doesn’t exist, code reviews become a way to effectively spread knowledge out amongst the engineers.

Objectives

Ensure Code changes are correct, maintainable, and fit for purpose.

Code Review Checklist

• Meets requirements with no premature optimisation / unnecessary complication
• Code review size / cognitive load considerations - split up large PRs where possible
• Identify the importance / risk of the changes
• Are the changes self-documenting
• Do the changes adhere to local reasoning
• View the surrounding code for context
• Has sufficient testing been added
• Has the functionality been unncessarily coupled
• Has a bad pattern been followed just to be consistent with the surrounding code