Code reviews are not effective at finding bugs
-
shepherdly[^]:
One of the biggest time sinks in software development is code review and approval.
Unless you count the "should this be InitializeWorkflow or StartWorkflow?" discussions as finding bugs
BeginStartInitializeWorkflow, of course
-
shepherdly[^]:
One of the biggest time sinks in software development is code review and approval.
Unless you count the "should this be InitializeWorkflow or StartWorkflow?" discussions as finding bugs
BeginStartInitializeWorkflow, of course
I always try my best to read every line of changed code in a review. I have found obvious bugs and requested changes. Sometimes you can even tell the developer didn't even bother to try and compile the code before submitting. Looking at you M****s. (Someone I used to work with.)
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
-
shepherdly[^]:
One of the biggest time sinks in software development is code review and approval.
Unless you count the "should this be InitializeWorkflow or StartWorkflow?" discussions as finding bugs
BeginStartInitializeWorkflow, of course
Hard to argue with the points even if the thesis put a cap in my knee. "First, the yield on finding bugs in reviews was about 15% of code review comments defects despite it being the top motivation." But I don't think that's the chief motivation. Rather, "meta" is. Was the approach a good one? Is there way better way? Are there fundamental oversights to the implementation? Are there code features that the reviewer learns from the review or that the reviewer can pass to the reviewed on account of the code in question being exhibition? Code style/staying within 'the lines'? Were the tests written? If they wrote tests, and you review those, there is a sort of comfort that the code doesn't have bugs. It's not 100% but...
-
shepherdly[^]:
One of the biggest time sinks in software development is code review and approval.
Unless you count the "should this be InitializeWorkflow or StartWorkflow?" discussions as finding bugs
BeginStartInitializeWorkflow, of course
Well, bugs usually involve the complex interplay of code from various different source files. I doubt that any code reviewer could spot that looking at one file at a time.
The difficult we do right away... ...the impossible takes slightly longer.
-
shepherdly[^]:
One of the biggest time sinks in software development is code review and approval.
Unless you count the "should this be InitializeWorkflow or StartWorkflow?" discussions as finding bugs
BeginStartInitializeWorkflow, of course
At my last job, code reviews were very effective. They covered more than bugs; they helped sanity check code design.
-
shepherdly[^]:
One of the biggest time sinks in software development is code review and approval.
Unless you count the "should this be InitializeWorkflow or StartWorkflow?" discussions as finding bugs
BeginStartInitializeWorkflow, of course
Code reviews aren't for testing code, that's what alpha and beta testing/UAT are for. Obvious bugs might be spotted, but that's not what the focus is on.
There are no solutions, only trade-offs.
- Thomas SowellA day can really slip by when you're deliberately avoiding what you're supposed to do.
- Calvin (Bill Watterson, Calvin & Hobbes) -
shepherdly[^]:
One of the biggest time sinks in software development is code review and approval.
Unless you count the "should this be InitializeWorkflow or StartWorkflow?" discussions as finding bugs
BeginStartInitializeWorkflow, of course
The secret of a successful code review | CommitStrip[^] :-D
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
