🏫
Obvious University
Website
  • 👋Welcome to Obvious University!
  • Strategy
    • Sprints
      • 1️⃣Map
      • 2️⃣Sketch
      • 3️⃣Decide
      • 4️⃣Prototype
      • 5️⃣Test
    • Benchmarking
    • Research
      • 1️⃣Research guide
      • 2️⃣How to recruit users
      • 3️⃣How to conduct an interview well
      • 4️⃣How to take notes
      • 5️⃣How to prep for remote research
      • 6️⃣How to throw a watch party
      • 7️⃣How to create artefacts
  • Working with Features
    • Building with AI
      • 1️⃣Understand the tech
      • 2️⃣Map your product
      • 3️⃣Build a proof of concept
      • 4️⃣LLM Inputs
      • 5️⃣LLM Responses
    • Building Help and Support
      • 1️⃣How to scope a support experience
      • 2️⃣How to design discovery for support
      • 3️⃣How to design a support centre
      • 4️⃣How to write good support articles
  • Product Design
    • Microcopy
      • 1️⃣How to write well
      • 2️⃣How to write phrases
      • 3️⃣How to write messages
      • 4️⃣How to create a voice
    • Typography
      • 1️⃣How to compose type
      • 2️⃣How to create a type scale
      • 3️⃣How to pick typefaces
      • 4️⃣How to pair typefaces
    • Design System
      • 1️⃣Introduction to design systems
      • 2️⃣How to audit a design system
      • 3️⃣How to run a design system pilot
      • 4️⃣How to set up a design foundation
      • 5️⃣How to build components
      • 6️⃣How to document a design system
      • 7️⃣How to enable adoption and govern a design system
    • Mobile Engineering
      • 1️⃣Trunk based development
      • 2️⃣Agile development terminology
      • 3️⃣Git commit messages
      • 4️⃣Code review and pull requests
      • 5️⃣Readings
  • Delivery
    • Project Management
    • Collaboration
  • Hiring and Growth
    • Growth
      • 1️⃣Design growth framework
      • 2️⃣How to give ongoing feedback
      • 3️⃣How to check-in every quarter
      • 4️⃣How to address underperformance
      • 5️⃣FAQs
    • Hiring and careers
      • 1️⃣The Hiring Process
      • 2️⃣Diverse and Inclusive Hiring
  • PEOPLE EXPERIENCE
    • Benefits and Perks
      • 1️⃣Paid time off
      • 2️⃣Insurance and healthcare
      • 3️⃣Continuing education
      • 4️⃣Speaking at conferences
    • Starting at Obvious
      • 1️⃣Introducing Obvious
      • 2️⃣Set up your workspace
      • 3️⃣Onboarding
      • 4️⃣Finances
      • 5️⃣Code of Conduct
    • Employment policies
      • 1️⃣Equal opportunity employment
      • 2️⃣At-will employment
      • 3️⃣Employee records and privacy
      • 4️⃣Prevention of sexual harassment
      • 5️⃣Drugs and alcohol
      • 6️⃣Fraternisation
      • 7️⃣Non-compete and non-solicitation
      • 8️⃣Non-disclosure
Powered by GitBook
On this page
  • 👋 Introduction
  • 1️⃣ Reviewing code
  • 2️⃣ Assigning a PR
  • 3️⃣ Helpful tips
  • Further reading
  1. Product Design
  2. Mobile Engineering

Code review and pull requests

PreviousGit commit messagesNextReadings

Last updated 1 year ago

👋 Introduction

Code reviews ensure standards and guidelines are respected and followed. Sure, code reviews can (and do!) help with catching mistakes early on, but in large codebases, techniques like test-driven-development are far more effective for writing bug-free code.

Code reviews are an opportunity for discussion and evaluation; a chance for novice engineers to get feedback on their ideas from senior ones, and a time for senior engineers to walk the rest of the team through their thought process.

1️⃣ Reviewing code

It is the code that is being reviewed, and not the person who wrote it!

  • Many programming decisions are opinions and not facts. When discussing tradeoffs, ensure it doesn’t lead to bike-shedding and a cost-benefit analysis is done -- “What is the cost of discussing this thing for 60 minutes? What is the benefit or drawback of picking a choice? Is it worth our time?”

  • Ask questions and don’t demand changes. Good questions avoid judgment and avoid assumptions about the author's perspective.

  • Don’t use hyperbolic words and avoid all sarcasm. Temper your communication, sit down, stay humble.

Avoid selective ownership of code. Eventually, it is the team’s code and the entire team has to share the responsibility of maintenance. Team and project standards are much more important than personal opinions. When disagreeing, first commit to using the prevailing standard. Discuss the standard later... right here, in the handbook! Just .

2️⃣ Assigning a PR

You can automate this using !

  • In a round-robin fashion, assign your PR to a team member. This should be done without asking them. Everyone should be coding and reviewing at all times.

  • If you think your PR is non-trivial and needs more than one pair of eyes, then assign it to two people. If you’re new to the team, assign it to two people.

  • If your PR isn’t reviewed in the next 24 hours, talk to the assignee in person and figure out what’s happening. Maybe they're busier than usual and need a helping hand?

3️⃣ Helpful tips

  • It is often easier to follow the author's train of thought by reviewing a PR commit by commit, instead of reading the entire diff file by file.

  • When commenting on an intermediate commit in a PR, one should first make sure that the comment makes sense when the complete PR is seen as a whole. Because the author may have already addressed the concern in another commit down the PR.

Further reading

If you're reviewing on itself, there are you can use!

, on the Google engineering practices website.

4️⃣
open a pull request
a tool like PullAssigner
github.com
handy keyboard shortcuts
How to do a code review