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

Programming

13389 readers
33 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
20
What does your merge/code review process look like? (beehaw.org)
submitted 1 year ago by pattern@beehaw.org to c/programming@beehaw.org
33 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
[–] mustyOrange@beehaw.org 1 points 1 year ago* (last edited 1 year ago) (1 children)

Midwestern b tier company:

  1. Test your code on its own branch. Make sure it's not fucked

  2. Pr to dev, do code review with devs that call you out on your bullshit (were all lazy sometimes)

  3. Whip up QA doc, send the ticket to the QA queue

  4. Confirm with BU that all their bases are covered and nothing is missing

  5. Repeat steps for inevitable wishy washy scope creep from BA who wants to have inevitable meetings that could be done in emails

  6. Complete merge to dev, merge dev to master, and tell devops that it's ready to go

[–] pattern@beehaw.org 1 points 1 year ago

Ah yes, sounds about right. I particularly prefer the "make sure it's not fucked" step, very effective😂 I'd like to get more formal code reviews in place with my current team, I think we could all benefit.