Yeah it’s probably one of our more hotly discussed issues at eng. catch-ups. A few newer starters come from more startup backgrounds and find it super frustrating.

Pros & cons as with any process 🤷

I love this song. I never really checked out any of their other stuff though

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