4 ms·
There’s no good reason for any team of 2 or more to not do code reviews.
by sidlls 3y ago
There’s no good reason for any team of 2 or more to not do code reviews.
- junofan 3y agoI even do it solo. Why not proofread?
- mathgeek 3y agoCode review generally requires a peer to do the reviewing, so most folks would likely say that doesn’t count. I was curious if it would, but the first couple pages of googled results confirm the peer aspect.
- thfuran 3y agoThat's certainly better than reviewing your own code, but tossing your code into a merge request to run tests and then taking another look over it tomorrow if it's all green is still better than just pushing straight to prod because there's not another pair of eyes.
- Izkata 3y ago> but tossing your code into a merge request to run tests and then taking another look over it tomorrow Or even just immediately. I often find minor issues just by looking at it in a different context (the merge request vs my editor).
- mathgeek 3y agoNaturally. That’s a different process from a code review though, which is what this thread is discussing.
- Bellend 3y agoThat seems almost ridiculous? You commit code that you wrote and then Code Review your commit and then verify it? Doesn't that happen as part of the original commit by common sense?
- recursive 3y agoYou might have never seen the diff all at once.
- Bellend 3y agoBut you wouldn't commit that as there are multiple tools to review a commit before you literally stamp your name on that commit? Otherwise you are generating noise for your teammates.
- Klaster_1 3y agoIn practice, reviewing your own code in a different context really makes a difference, at least for me. Not sure why, but I always notice things I wouldn't before. The same effects holds true even for regular text - as much as I try, proofreading my writing in editor yields subpar results compared to reading a submitted message, I simply fail to notice even the most blatant mistakes. I wonder if this effect has a name.