Difference between revisions of "Code review"
Jump to navigation
Jump to search
m |
m (→Guidelines) |
||
| Line 7: | Line 7: | ||
# Code reviews (CRs) are '''strongly recommended''' for any non-trivial code change, but not mandatory (nor enforced at the VCS level). | # Code reviews (CRs) are '''strongly recommended''' for any non-trivial code change, but not mandatory (nor enforced at the VCS level). | ||
# The CR [[Code review in Phabricator|'''workflow''']] is implemented using Phabricator/Differential. | # The CR [[Code review in Phabricator|'''workflow''']] is implemented using Phabricator/Differential. | ||
| − | # Explicitly '''suggest reviewer'''(s) when submitting new CR requests: either the most knowledgeable person(s) for the target code or the general [https://forge.softwareheritage.org/project/view/50/ | + | # Explicitly '''suggest reviewer'''(s) when submitting new CR requests: either the most knowledgeable person(s) for the target code or the general [https://forge.softwareheritage.org/project/view/50/ reviewers] group (which is the [https://forge.softwareheritage.org/H18 default]). |
# '''Review anything you want''': no matter the suggested reviewer(s), feel free to review any outstanding CR. | # '''Review anything you want''': no matter the suggested reviewer(s), feel free to review any outstanding CR. | ||
# '''One LGTM is enough''': feel free to approve any outstanding CR. | # '''One LGTM is enough''': feel free to approve any outstanding CR. | ||
Revision as of 12:58, 12 October 2018
This page documents code review practices used for Software Heritage development.
WORK IN PROGRESS page
Guidelines
- Code reviews (CRs) are strongly recommended for any non-trivial code change, but not mandatory (nor enforced at the VCS level).
- The CR workflow is implemented using Phabricator/Differential.
- Explicitly suggest reviewer(s) when submitting new CR requests: either the most knowledgeable person(s) for the target code or the general reviewers group (which is the default).
- Review anything you want: no matter the suggested reviewer(s), feel free to review any outstanding CR.
- One LGTM is enough: feel free to approve any outstanding CR.
- Review every day: CRs should be timely as fellow developers will wait for them. To make CRs team-sustainable each developer should allocate a fixed minimum amount of time for doing CR every (work ☺) day.
For more detailed suggestions (and much more) on the motivational and practical aspects of code reviews see Good reads below.
Good reads
Good reads on various angles of code review:
- Best practices (Palantir) ← comprehensive and recommended read, especially if you're short on time
- Best practices (Thoughtbot)
- Review checklist (Code Project)
- Motivation: team culture (Google & FullStory)
- Motivation: code quality (Coding Horror)
- Motivation: humanizing peer reviews (Wiegers)