this post was submitted on 08 Jun 2023
5 points (100.0% liked)

Programming

13376 readers
1 users here now

All things programming and coding related. Subcommunity of Technology.

This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 2 years ago
MODERATORS
alyaza@beehaw.org
Hexorg@beehaw.org
remington@beehaw.org
5
What does your merge/code review process look like? (beehaw.org)
submitted 1 year ago by pattern@beehaw.org to c/programming@beehaw.org
8 comments fedilink hide all child comments
 

Hey all! My team at work is struggling with growing pains of getting into a formalized review process, so I was wondering if any of you guys have some things to live or die by in your code reviews. How much of it is manual, or how much is just static code analysis + style guide stuff, etc?

you are viewing a single comment's thread
view the rest of the comments
[–] nigel_peters@lemmy.nz 1 points 1 year ago

Ours is pretty intense - large bank, 60 or so iOS engineers actively contributing to a mono-repo:

  1. We have about 15 CI steps that pick up on anything from basic linting to security concerns (SonarQube). Unit tests, UI tests, etc.
  2. We have a template that PR authors follow to add descriptions, test plans, devices tested on.
  3. Reviewers are automatically assigned using a round robin system
  4. Reviewers obviously review the code, but also execute the test plan, which includes accessibility testing.
  5. All PRs require 2 approvals.
  6. A bunch of other stuff (uploading artefacts, generating gRPC protos) that probably isn't worth going into detail.

It's intense, and PRs on average take a week or so to get merged. In saying that, it is the highest quality and most well-architected codebase I have ever worked on.

If I were in your situation I'd push for the following:

  • all PRs have one approval, preferably two depending on team size
  • code is tested by someone else before being merged to main
  • use linters, Danger, etc to pick up on trivial shit
  • a few manual checks like ensuring code is unit tested
  • a Github PR Reviewer guide describing common issues to look for, tone of messaging when leaving comments ("be nice", "make it clear when you are adding optional nit-picks", etc)
  • encourage authors to add review comments to their own PRs for any bit of code that isn't immediately obvious
  • stretch goal: look into generating code coverage reports on your PRs, add quality gates