4 - Perfecting The Pull Request

Summary:

This episode of the Bikeshed Podcast features Scott Kaye, Matt Hamlin, and Dillon Curry discussing best practices for code review, with a focus on creating effective pull requests (PRs) and how to approach reviewing code.

Creating Great Pull Requests

• Context is Key: Highlight the problem being solved, the goal of the PR, and the solution chosen. Explain why this solution was selected over alternatives.
• Scope: PRs should be isolated to a single problem or feature.
• Rollback: Consider and outline the rollback procedure for changes.
• Templates: Minimal templates with "context" and "details" sections are generally preferred. "Alternatives Considered" can be a useful addition.
• Self-Review: Conduct a self-review of the code, ideally within the GitHub PR interface, to identify potential issues.
• Draft Mode: Utilizing draft PRs is helpful for iterative development and early feedback.
• Visual Aids: Include screenshots, screen recordings, and preview deploys to contextualize changes, especially for UI-related PRs. Dev tool screenshots can be helpful.
  • How to capture full-size screenshots within Chrome DevtoolsOpens in new tab
  • Matt's replacement for Dropbox CaptureOpens in new tab
• Tests: Defer writing tests until a solid solution and some initial feedback have been received to avoid wasted effort due to significant code changes.

Reviewing Code Effectively

• Understand the Big Picture: Start by understanding the problem being solved and the overall goal of the PR.
• Use Available Context: Utilize videos, screenshots, and preview deploys to understand the changes.
• Prioritize: Focus on major changes and save minor issues for a second pass.
• "What, Why, How" Approach: Consider what the change does, why it's being made, and how it's implemented.
• Live Reviews/Pairing: For complex changes, consider live reviews or pair programming to accelerate feedback and build shared understanding. However, acknowledge that this is not always feasible due to time constraints.
• Knowledge Sharing: Use code reviews as an opportunity to onboard team members and share knowledge.

Spicy Takes (and Not-So-Spicy Takes)

• Code review maybe is not needed: It was suggested in certain situations, code review may not be necessary. This take was received as extremely situational.
• You should almost never have to do two code reviews This take was received as neither mild or spicy, more so cold and lukewarm.

What's Up With You? (Stand-up Updates)

• Dillon: Was looking into something called embargoed assets in Contentful.
• Scott: Learned about animating on scroll videos and pictures in React using the Canvas tag, bypassing React's re-rendering limitations.
• Matt: Investigating Content Security Policy (CSP) and durable objects on Cloudflare.