Best Practices
Code reviews are methodical assessments of code designed to identify bugs, increase code quality, and help developers learn the source code.
GitLab
Author: who writes the code.
Reviewer: who reads the code and decides when it’s ready to be merged into the team’s codebase.
Changelist: a set of changes to source code that the author wants to merge.
Rounds: complete round-trip between the author and reviewer.
Approvers: green light reviewers.
Share knowledge
Discover bugs earlier
Maintain compliance
Increase collaboration
Automated Checks
After
Before
But
Should happen
Whitespaces, indentations, Styling, Automated Test, Unused variables, Formatters, Builds etc...
Use CI/CD servers.
Code reviews should be easy to review so as not to waste reviewers' time and motivation.
- What should we review?
- How to give feedback?
Scope and size
The changes should have a narrow, well-defined, self-contained scope
Only submit complete, self-reviewed, and self-tested Pull Requests.
Automate as much as possible
Add as much context as possible
Add the ticket, description, possible breaking changes, add labels, reviewers and assignees.
Follow Git Guidelines
Find the reviewers
Scope and size
Follow Git Guidelines
Code reviews are classless
Being the most senior person on the team does not imply that your code does not need review.
Purpose
Legibility and style
Implementation
Give Constructive Feedback
Maintainability
Pair Programming FTW
Source: https://mtlynch.io/human-code-reviews-1/
Legibility and style
Add context
Use the GitHub Files Tree
Use the viewed button
Be generous with examples
Comment, Approve or Request Changes
Code review provides an opportunity for mentorship and collaboration.
Code review process diversifies the understanding of code in the codebase.
Return on Investment (ROI)