Programming

28928 readers

428 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 3 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

UlrikHD@programming.dev

bugsmith@programming.dev

Spyro@programming.dev

Tips for Reviewing Code (lemmy.world)

submitted 1 day ago by galaxy_nova@lemmy.world to c/programming@programming.dev

21 comments fedilink hide all child comments

Hello all. I work on a small team and I’ve been tasked with taking on the bulk of code review for when my senior goes on leave. Although I’ve read a fair bit of code (man am I lucky I learned to code before AI “got good”) I can’t say I’ve done a lot of actual “review”. Does anyone have any tips? I feel responsible if anything breaks after I review it so of course I want to avoid that.

you are viewing a single comment's thread
view the rest of the comments

[–] ultimaluz@lemmy.world 4 points 1 day ago

on the fear part, in a healthy team the author still owns the change, the reviewer is a second pair of eyes not an insurance policy. what helped my people a lot was asking the author how they tested it and what happens if it goes wrong, if they can't answer that's your review comment right there. and if something breaks after you approved it, you fix it together and add a check so it doesn't happen again, nobody serious blames the reviewer for that