DEV Community

Discussion on: How to code review in a start up?

Collapse
 
sebbdk profile image
Sebastian Vargr • Edited

The way i have done it in small teams have always been treating PR's more like sanity checks. I find trusting your team is much better than scrutinizing them. :)

This is how the process i usually encourage is:

  • Each pr needs to be approved by 1 other developer
  • Keep PR's small, a code-review should be doable in 5-10 minutes and should not require the reviewer to test things, it's a code review, not a test.
  • ignore code-style as much as possible, install a lint-fixer, like Prettier, if it is a problem in the team.
  • if you lack a reviewer with the proper language skills pull someone else over and explain the code to them, it's works the same in terms of sanity checks.
  • Always side with whatever fixes the problem now, if there is a "better" way it can always be done in a followup PR. And if all else fails look for someone more senior and hear them out.
  • The lead/senior dev' on the team can always overrule above when the need arise.

I find doing it like this keeps productivity high and style debates at minimum.
Of cause, this approach is more suited for small contained teams where a occasional bug getting past developers and onto the testers is not a problem.

I also usually highly encourage developers to read up how to behave on PR's.
It is a sensitive situation, especially for juniors, and deserves to be treated with respect to avoid pissing someone off because of a stupid misunderstanding. :)

Collapse
 
ruvans profile image
Ruth Evans

This is great advice, thank you! Especially about using a lint fixer as I find most disagreements are over simple code style