pair code review lightning talk
TRANSCRIPT
Lightning Talk: Pair Code ReviewDan Levenson
Who’s Speaking?
● dlevenson.com
● dleve123 on twitter, github, etc.
● CTO @ healthify.us
The Problem
The Problem
Development Workflow
1. Start story in Pivotal Tracker2. Implement story3. Open pull request4. Participate in code review (CR)5. Merge PR6. QA on staging and manually deploy to
production
Stepwise Code Review Protocol
1. Developer assigns a reviewer using Github’s pull request (PR) assignee functionality
2. Developer explicitly requests CR via Github comment
3. Reviewer reviews via Github comments, developer performs revisions, and repeat
4. Reviewer merges PR
Stepwise CR: Takeaways
● Not “Agile”: No face to face conversation
● “This is so simple. I’ll review it later”○ later → much too late.
● Dead time due to lack of CR scheduling○ Large PRs are daunting → even longer dead time
Pair Code Review: Motivation
● Old process intuitively inefficient
● Scrum → Kanban○ minimize cycle time
Pair Code Review: Protocol
1. Developer and reviewer agree on a 1 hour time period ASAP
2. Reviewer leads review and asks developer questions
3. Reviewer comments on PR to document action items generated from CR
4. Developer revises (usually only 1 time)
Some Progress
Some Progress
Pair CR: Takeaways
● Pros○ Scheduling → less dead time
○ Long comments replaced by quick conversations
○ Breeds pairing culture
● Cons○ Bias of the developer can affect reviewer