Mob review is a real-time code-review practice: the team examines one developer’s change together through a clearly shared screen and live communication. section 12.2.1
The group brings diverse expertise to the change, shortens the feedback loop, aligns the author with team goals, and strengthens shared codebase ownership. section 12.2.1
Choose the role mob review plays in the workflow:
- Use it for an unusually large pull request when several reviewers can reduce pressure and improve the change before an urgent merge. section 12.2.1
- Use it as a distinct collaboration mode: the team reviews code together rather than producing code together. section 12.3
- Combine it with capture and chronicle by recording key observations, decisions, context, and skipped alternatives in the pull request. section 12.2.1
Emergency review for a large pull request
A seven-person team reviews a large pull request together when management constraints require a fast merge. The shared effort improves the change, distributes review pressure, and helps teammates reference other parts of the codebase. section 12.2.1
Table 12.1 Lightweight chronicle PR checklist
|
Checklist Item
|
Information to chronicle
|
Examples
|
|---|---|---|
|
Why/context
|
• Why are we making this change? What’s the context behind this change?
• What decisions led to this solution?
• How did we come to an agreement on this solution?
|
“This change addresses a really esoteric edge case we didn’t catch but recently caused a major production issue (#323).”
“We have to use this (rather than the FetchUser function available in version 9.3) because our internal packaging system is pinned to version 8.9.6. Until this has been updated company-wide, we have to continue using this workaround method.”
|
|
Skipped solutions
|
• What alternative solutions were discussed, and why were they skipped?
• What “gut-feeling” solutions turned out to be wrong?
|
“We considered Next.js, but they don’t seem to support relative paths for the exported content. They still have an open ticket on GitHub requesting this support, but they are ignoring it.”
“Lambda Functions incur an additional charge when writing to S3, so we skipped.”
|
|
Considerations (brought up during mobbing)
|
• Will these changes impact other teams?
• Other parts of the code base?
• Does this need to be deployed in a certain way?
|
“This needs to be feature-flagged until the corresponding ‘Seller’ component is ready.”
“With this refactor, we can remove the AccountUtilities library entirely. Let’s place that work in a separate PR, though!”
|
Use the lightweight pull-request checklist to record why the change exists, which decisions shaped it, and which alternatives were rejected. section 12.2.1
