Skip to content

Instantly share code, notes, and snippets.

@Haelle
Last active July 16, 2017 17:12
Show Gist options
  • Save Haelle/ab2c1e6c9b5747ac80f533c4de3301e6 to your computer and use it in GitHub Desktop.
Save Haelle/ab2c1e6c9b5747ac80f533c4de3301e6 to your computer and use it in GitHub Desktop.
Checklists for Software Development

Checklists for Software Development

Patrick Joyce - pragmati.st/checklists

Before Submitting a Pull Request

THE SUBMITTER SHOULD ALWAYS ASK THEMSELVES THE FOLLOWING QUESTIONS:

  • Have I looked at every line of the diff between your branch and master?
  • Is there anything in this patch that is not related to the overall change?
  • Have I structured the commits to make the reviewer’s job easy?
  • Have I tested the code locally?
  • Should QA look at this before I submit it for review?
  • Does the Pull Request explain how to verify that the feature is working?

When Reviewing a Pull Request

THE REVIEWER SHOULD ALWAYS ASK THEMSELVES THE FOLLOWING QUESTIONS:

  • Do I understand the goal of this change?
  • Have I looked at every line of the diff between the branch and master?
  • Have I used the code locally?
  • Should this go through additional QA?
  • Are there sufficient unit and functional tests?
  • How will we know if this change “works”?

Before Deploying

THE SUBMITTER AND REVIEWER SHOULD ALWAYS TAKE A MINUTE AND ASK EACH OTHER THE FOLLOWING:

  • What are we worried about going wrong?
  • Is there anything different about this change in production vs. in dev / staging?
  • Is now an optimal time to deploy this change?
  • Is it possible or desirable to roll this out to a subset of our users?
  • What specific steps will each of us take when the deploy finishes to verify that the changes work?
  • If something goes wrong, what will we do? Is this safe to revert and re-deploy?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment