Alternatives to Pull Requests

Jesse Warden - Dec 27 '23 - - Dev Community

If you’re tired of reviewing PR’s, you have other options. I’ll list some of the tradeoffs, but they’re worth a try if you’re losing patience and feel PR’s are taking too much time and break focus.

Check into main/trunk instead of making branches

https://minimumcd.org/minimumcd/#trunk-based-development

Pros: No more branches, no more merge fiascos, faster delivery of code assuming your main branch is pushed to some higher environment.

Cons: Git still can merge things automatically that are wrong, team has to take initiative to review code on their own, often having to “catch up on their reading”. If you don’t have good types and automated tests, this can wreak havoc. Small evidence shows TBD can stress out mid to junior developers vs opposite for seniors.

Option: Continuous Code Review
https://thinkinglabs.io/articles/2023/05/02/non-blocking-continuous-code-reviews-a-case-study.html

Pair Programming – 2 coders at 1 keyboard

https://en.wikipedia.org/wiki/Pair_programming

Pros: Code is designed & reviewed in real-time. Evidence shows it sometimes is more efficient having 2 developers working on 1 task vs “2 coders doing 2 tasks at the same time” as well as better quality code.

Cons: Team has to swap roles & rotate on a schedule so same 2 devs don’t get paired. Some devs don’t like other certain team members. Some devs want to get into flow state alone. Can be extremely tiring for some devs despite them enjoying it.

Option: Doesn’t have to be everyday, all day.

Mob Programming – entire team at 1 keyboard

https://thinkinglabs.io/articles/2023/05/02/non-blocking-continuous-code-reviews-a-case-study.html

Pro: Similar to Pair, but task truly is a “team effort”; entire team takes responsibility for a feature, code reviewed in real-time, entire team possibly “knows that section of the code base”.

Cons: Same for pair programming, but sometimes worse. Entire team can be deadlocked on an argument (aka “hung jury”), and make no progress; tradeoffs for having an arbiter.

Options: Attendance is not required, and people can drop out as needed (meetings, errands, build failure on other team, etc).

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .