

Code Reviews should be the universal rule of serious Software Development - manish_chhabra
http://blog.manishchhabra.com/2012/12/code-reviews-should-be-the-universal-rule-of-serious-software-development/

======
tsewlliw
Reviews are undeniably important. I've spent a far above average time on this
problem when I was on the dev team for CodeCollaborator so I feel qualified to
suggest:

a) its a code review, not an author review

b) be respectful of your reviewer's time:

1\. 200 lines is a big review obligation, 500 lines should be a hard maximum.
Remember that boilerplate code does have meaning, and it counts. If you can't
make time for reviews, then don't rubber stamp, just don't review.

2\. Run whatever automation and analysis is available to you before submitting
for review, and fix what it tells you to fix or note the trigger and document
why its a false alarm.

3\. You may count unit test code at 1/3 the normal rate, and even get 50 lines
totally free. This relieves the burden of mentally running your code, and
makes it easy to request additional test cases, which will be easier on your
ego than bugs.

All the big problems people have with code reviews are about checking your
ego, respecting your peers, and clear communication.

------
smurph
I've had a lot of trouble with this at my current job. There's a strict policy
that requires a review before anything makes it in to a deliverable branch,
but there's also a culture of emergency fire fighting where they will expect
problems fixed quickly, often outside of working hours when a code review
isn't really possible. So far our team's done full blown reviews for all new
components, but we've waived reviews for small bug fixes. One big hurdle is
that we are using proprietary source control software that does not play nice
with any of the established review tools (another battle I am trying to
fight.).

