Comments on: Don’t Snub the Code Review

By: Hunting Down The Mythical High Quality Code - Simple Programmer

Hunting Down The Mythical High Quality Code - Simple Programmer — Thu, 07 Dec 2017 16:43:58 +0000

[…] is definitely more than one opinion regarding the format of code reviews. John suggests implementing pair programming since that way ego doesn’t get in the […]

By: Marco Willemart

Marco Willemart — Thu, 04 Aug 2016 13:17:00 +0000

A few years ago I read a research paper (cannot remember the reference, sorry) that found that code review can detect up to 80% of bugs, compared to unit testing for example that scores much lower. This is somewhat surprising but by experience I think it makes sense.

I like pair programming and find it useful, especially when a senior is paired with a junior for example. Otherwise I find that more work can be done if each developer is experienced enough and works on a separate task.

In my team we put a strong emphasize on design by contract, so each abstraction (class, method,…) is specified along with the invariants it supports. When I review such code and I know the developer is experienced enough, I barely look at the implementation but rather focus solely and very carefully on specifications (pre, post, invariants, etc), which constitute the design of the application after all. Such reviews are usually fast and very effective at detecting potential problems.

By: Spencer Darosa

Spencer Darosa — Sat, 15 Jan 2011 09:19:05 +0000

I admit, I have not been on this webpage in a long time… however it was a further joy to see It is such an essential topic and ignored by so many, even professionals. I thank you to assistance making people more aware of doable issues.

By: Kevin Watkins

Kevin Watkins — Thu, 10 Jun 2010 10:00:02 +0000

One thing I have seen happen a few times with pair programming is that both programmers will make the same mistake, presumably because they’re following the same train of thought and are locked into solving the same problem. I’ve seen this happen less with separate code reviews simply because the reviewer is coming in fresh to the problem.

Of course I have seen problems and issues escape with both approaches; nothing is perfect!

I believe pair programming really shines when you need to teach someone something, be it a part of your codebase, a new technology or whatever. There is nothing better than jumping in and coding to explain coding!

By: Joe Green

Joe Green — Thu, 10 Jun 2010 05:16:51 +0000

WTFs/minute is truly the the only valid measurement 🙂 I would highly recommend the book “Clean Code” (where I believe the image was pulled from) to anyone looking to tighten their skills.

By: Derick Bailey

Derick Bailey — Wed, 09 Jun 2010 20:36:41 +0000

In reply to jsonmez.

i like the change… makes it very clear, and i 100% agree. … so here’s your next challenge: solve the problem of distributed continuous code (and design) review. 🙂

By: jsonmez

jsonmez — Wed, 09 Jun 2010 20:21:08 +0000

In reply to Derick Bailey. Oh, I see what you mean there. I think I did misuse the word. I will update it. What I am trying to say is that it is positive reinforcement for a negative action. Essentially it is reinforcing the negative action. Let me word that better. Thanks for catching that.

By: Derick Bailey

Derick Bailey — Wed, 09 Jun 2010 20:13:14 +0000

i think you misused “negative reinforcement”… can you expand on why you think that is negative reinforcement?