In my experience, every shop has a different definition of the term "code review". When I was at $LARGE_VIDEO_GAME_COMPANY, a "code review" was a pre-checkin (to Perforce) meeting with the nearest cubemate, at your computer, showing them diffs. It was designed to be as short as possible, but had a good bang-for-the-buck since simple little things could be caught very quickly by another person doing a sanity check.
In contrast, "code review" at my next full-time job inspired dread of 3-hour all-hands meetings where a big group would go over code, line by line, ages after it was submitted to the repo.
I'm solidly behind the former process. I've come up with a checklist of "pre-commit" tasks to do before someone checks in code to one of my project repos, which generally ensures that any changes submitted are tested, and as minimal as possible.
Comments
In my experience, every shop has a different definition of the term "code review". When I was at $LARGE_VIDEO_GAME_COMPANY, a "code review" was a pre-checkin (to Perforce) meeting with the nearest cubemate, at your computer, showing them diffs. It was designed to be as short as possible, but had a good bang-for-the-buck since simple little things could be caught very quickly by another person doing a sanity check.
In contrast, "code review" at my next full-time job inspired dread of 3-hour all-hands meetings where a big group would go over code, line by line, ages after it was submitted to the repo.
I'm solidly behind the former process. I've come up with a checklist of "pre-commit" tasks to do before someone checks in code to one of my project repos, which generally ensures that any changes submitted are tested, and as minimal as possible.