Skip to content

Code Reviews

Jump to bottom
Taylor Snead edited this page Aug 10, 2022 · 6 revisions

Resources

Authoring a Pull Request

  1. Push your code to a non-main branch named after your changes, like fix-audio-player-loading or add-backend-docs.
  2. Create a new pull request in GitHub.
  3. If there's a Jira ticket associated with your work, add it to the PR title. For example, [DP-111] Enable PostCSS auto-prefixing
  4. Describe the changes in the PR body.
    • Include screenshots of front-end changes, or at least instructions for how to verify changed functionality in the preview deployment. For example, "go to page X and click button Y to see the new feature".
  5. Request a review from at least one other team member.
    • Acknowledge all comments on your PRs as you read them. A response is best, but even a simple emoji reaction is way better than nothing.
    • If you don't understand a comment, respond with a question.
    • Always format your code before requesting a review. Having to comment about white-space and formatting is a waste of your reviewers time. prettier for TypeScript, rustfmt for Rust.
  6. Respond to review comments within a few days (the sooner the better)
  7. Once a reviewer has approved it, merge with a merge commit

Reviewing Pull Requests

  1. Respond to requests for review or review comments within 1-2 days. If you cannot, let the PR author know when you'll get to it.
  2. Look through the code on GitHub or check out the branch locally.
  3. Make sure it works as expected.
    • Evaluate at a high level whether changes match up with and meet the goal of the Jira ticket.
    • If changes are front-end only, evaluate the preview deployment. Click the "Details" button for the last check at the bottom of the PR. Screen Shot 2022-06-22 at 12 32 30 PM
    • If the PR includes back-end changes, check out the branch locally and run the full stack (dev-database, dev-graphql, dev-website)
  4. Review the code itself for best practices and coverage of edge cases. Keep in mind that ideally, a review should be used as a learning moment and a way to share knowledge above just a critique.
    • Click “Start Review” so you can go back and edit pending comments before finishing your review.
    • Leave overall design comments in the written section on finishing the review. You can also provide applicable resources as links.
  5. Leave comments on the PR.
    • Add comments on specific lines, or drag to add comments across multiple lines.
    • Provide as much justification for your comments as you can:
      • Why do you think a certain change would be better?
      • Why are certain changes permissible?
      • What were you expecting as a reviewer?
  6. Cycle through the previous steps as new changes address your comments.
    • After a first pass, leave comments on the “Comment” level-- use “Request Changes” for pressing feedback.
  7. Approve the PR once you feel like all actionable feedback has been addressed.
Clone this wiki locally