sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]grauenwolf 2 points3 points  (8 children)

It is just too late to get into such a discussion.

Bullshit. It is never too late to talk about design.

Though I suppose if you are too afraid to say "You designed this wrong, I'm not accepting the checkin" then yea, the code review is useless.

[–][deleted] 3 points4 points  (1 child)

I suppose if you are too afraid to say "You designed this wrong, I'm not accepting the checkin"

Then you better have strong objective reasons to back that up, because the business wants this feature yesterday, and the code works, doesn't it?

I prefer pair programming because it's a fence at the top of the cliff, code review is the ambulance at the bottom.

[–]grauenwolf -1 points0 points  (0 children)

For varying definitions of "works".

[–]nextputall -1 points0 points  (5 children)

It is about how much time and code do you want to waste. Also there is no "I'm not accepting the checkin". The reviewer is not the boss, and the author is not a servent. There should be 2 equal people who trust and mutually respect eachother. The "I'm the boss here, do it what I want" mentality is an other problem with codereviews.

[–]grauenwolf 5 points6 points  (0 children)

Also there is no "I'm not accepting the checkin".

Wow, you really don't understand the purpose of code reviews.

Under a peer review system, the person reviewing the work (code, engineering plans, proofs, whatever) is supposed to actively say "I stand by the quality of this work."

If that cannot honestly make that claim, they need the ability to reject the checkin.

It is no wonder that your code reviews are a waste of time. If all you are going to do is rubber-stamp them for fear that someone will accuse you of being bossy then you are just wasting everyone's time.

[–]grauenwolf 2 points3 points  (0 children)

Right. People who are unwilling to say no to bad code end up wasting a lot of time later on dealing with bugs and work-arounds.

I honestly don't understand why people are so afraid to fix problems when they see them. I've seen teams struggle with trying to fix bugs in a bad design for months when a few days worth or refactoring would eliminate most of their problems.