nigel_peters

joined 1 year ago
[โ€“] [email protected] 3 points 1 year ago

I'm pretty sure I'll be getting one, but then again I'm an iOS developer and will likely be playing around with developing apps for it.

I can definitely see myself using this in the (home) office and around the house. Purely for productivity this looks like it'll be amazing

[โ€“] [email protected] 1 points 1 year ago

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 ๐Ÿคท

[โ€“] [email protected] 7 points 1 year ago

This is cute af. I love it

[โ€“] [email protected] 3 points 1 year ago (3 children)

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

[โ€“] [email protected] 4 points 1 year ago (3 children)

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