[Bellend]

When does code review kick in? Is it based on say a 10 person team or a 100 person team? Somewhere in-between?

[sidlls]

There’s no good reason for any team of 2 or more to not do code reviews.

[peyton]

I even do it solo. Why not proofread?

[mathgeek]

Code 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]

That'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]

> 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]

Naturally. That’s a different process from a code review though, which is what this thread is discussing.

[thfuran]

It's the same process as code review. It is code review.

[Bellend]

That 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]

You might have never seen the diff all at once.

[Bellend]

But 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]

In 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.

[Thaxll]

You should never submit and merge code that was not reviewed, no matter the size of the team.

[oxfordmale]

Why?

Does this apply to prototypes too?

If you are a team of two, and once of them is on holiday, do you wait until they come back?

[tkiolp4]

My take: if you submit code without the approval of your peers, and that code causes a noticeable issue in production… well, everyone will think “if only they have added me as a reviewer we wouldn’t have this issue!”. Sure thing, the bug could still exists in prod even after peer review, but then at least that would have meant that the bug wasn’t easily discoverable (i.e., the author and the reviewers missed it).

If you think you’re smart enough to submit code without bugs and without peer review, that’s fine. Take into account that your peers may not think you are that smart if you do that. Software engineering is mostly about dealing with people (well, almost everything in this world is about that).

Obviously if there’s no one to review your code, you may as well go ahead and push it without approval (unless your company has policies against that).