1. 6
  1.  

  2. 4

    The article focuses on the discrepancy between the people interviewed saying they thought finding defects was the main purpose of code review and the fact that it doesn’t do that very much. I think that’s just an indicator that those particular developers don’t really understand the purpose of code review. My team is only 5 developers and we know that’s not the main purpose, it’s to make sure the code conforms to standards, is readable, is the best it can be and to disseminate knowledge amongst the team.

    1. 1

      I would heavily stress that last point. In my eyes, after the first 3-6 months of employment, everyone should be following best practices for the code they create. If not, either the developer will never get it right (and should probably either be replaced, or given time to explain why the current way is wrong, depending on the situation), or the code review process isn’t functioning and needs to be reevaluated. Giving regular code reviews is still important, after that point, because it gets everyone up to speed on the parts they didn’t write. Knowing the system is far more important, in my eyes, than being an exceptional developer.

    2. 1

      I disagree with the author’s premise that code reviews are a good way to find defects. They are not good at that. That is what automated tests are for. Code reviews are good at keeping code readable.

      1. 2

        That’s a pretty bold claim, and one that dismisses valuable opportunities for engineering.

        Do automated tests find all the bugs that code review would? Perhaps. Does code review have other benefits that tests are less likely to provide? Perhaps. (The post discusses research suggesting this.) Would the tests with sufficient coverage to provide the same value take 10x as long to write and maintain? Perhaps. (Does the cost differ by language/platform, or team size? Perhaps.) Is there a sweet spot where a pass of code review helps to spread knowledge and catches a useful subset of bugs in a much smaller time than writing exhaustive tests would? Perhaps.

        There are many kinds of testing (property-based testing or fuzz testing may have very different costs and benefits than thorough-coverage unit testing, for example), and there’s also variety in code review practices. Any real comparison of their value will need to be a lot more specific than “They are not good at that.”.