Palantir Technologies article about insights and best practices for code reviews. Organizations with deep cultural reluctance to peer reviews may want to consult Karl E. Wiegers’ excellent essay on Humanizing Peer Reviews before trying to follow this guide.
We perform code reviews (CRs) in order to improve code quality and benefit from positive effects on team and company culture.
Authors cover the following topics:
- Why, what, and when to do code reviews
- Preparing code for review
- Performing code reviews
- Code review examples
Authors claim that committers are motivated by the notion of a set of reviewers. They tend to clean up loose ends, consolidate TODOs, and generally improve the commit.
Sharing knowledge helps development teams in several ways, including added/altered/removed functionality communication, using the technique or algorithm that reviewers can learn from, can help raise the quality bar across the organization, or strengthens social bonds between team member.
There is no eternally true answer to this question and each development team should agree on its own approach. Some teams prefer to review every change merged into the main branch, while others will have a “triviality” threshold under which a review is not required.
Examples and further reading provided. Interesting read, recommended!
[Read More]