Source originale du contenu
We do a bunch of code reviews at Sprint.ly. One of the things we've done to make that process a little easier is institute a code review template. This template is a free-form list of questions that every person filling out a pull request uses.
Our pull request template looks like this:
#### What's this PR do?
#### Where should the reviewer start?
#### How should this be manually tested?
#### Any background context you want to provide?
#### What are the relevant tickets?
#### Screenshots (if appropriate)
#### Questions:
- Is there a blog post?
- Does the knowledge base need an update?
- Does this add new (Python) dependencies which need to be added to chef?
Some sections get a "n/a", such as the screenshot section for API only changes. In general though, this has proven to make reviewing a much easier process. Curious what it looks like in practice? Here's an example from a recent pull request.
From just reading this, the reviewer is sufficiently caught up on what this change is, why it is important and how they should tackle this. Just a little of the author's time can save much more for the reviewer who often lacks context.
Do you have any techniques which makes your code review process smoother? Let us know!