We know that Code Reviews are a Good Thing. We probably have our own personal lists of things we
look for in the code we review, while also fearing what others might say about our code. How to
we ensure that code reviews are actually benefiting the team, and the application? How do we
decide who does the reviews? What does “done” look like?
In this talk, Trisha will identify some best practices to follow. She’ll talk about what’s
really important in a code review, and set out some guidelines to follow in order to maximise the
value of the code review and minimise the pain.
What to Look for in a Code Review (Blogs) -
the original blog posts for the content in the book, but also contains additional posts like
what to look for in Java 8 and 9 code (Java 10 and 11 post coming soon).
Code Review Best Practices at Palantir - effectively
a case study of one organisation’s approach to code reviews, including their “why”, “what”,
“when”, “who” and “how”, with a nod to “where”. Also includes details of how they categorise
[Code Review Tips and Recommendations](http://cr.openjdk.java
.net/~smarks/ocw2018/CodeReviewTips.html) - another case study, more or less in note form, of
code reviews for OpenJDK