DEV Community

Discussion on: I'm Changing How I Review Code

Collapse
 
masilver99 profile image
Michael Silver

I just don't know if this is practical. We have a 5 man team and require 2 approvals on most PRs. We can see anywhere from 0-5 PR's in a day. On a bad day I'll be doing nothing but PRs. And it could lock up all 5 developers if they examine them at the same time. But, there could be value in what you are saying, perhaps having a some PR's reviewed more deeply by a second developer, etc.

Collapse
 
jlouzado profile image
Joel Louzado

if you don't mind, what kinds of metrics is your team tracking to keep an eye on things? It sounds like you'll are a lean team and working hard on some ambitious goals, but if you're not keeping an eye on defect rate, lead-times or some kind of proxy metrics then it's easy to get trapped in a local-maxima of constant fire-fighting.

PR based workflow might actually be overkill for a small team though, so you might consider either:

  1. trunkbaseddevelopment.com/
    • super short-lived PRs, everyone's mostly working on main
    • feedback cycles will naturally shrink
  2. pair-programming
    • assign pairs that are stable for atleast a month
    • all code that's not pair-programmed must be code-reviewed
    • budget for lower productivity for a couple of days, but after that you should see much easier information flow in the team.