Talk:Code review

From Wikipedia, the free encyclopedia

Contents 1 Merge with software inspection 2 Initial development phase 3 Code review bias 4 "Idealistic wording" 5 Facts and figures from research 6 Dubious emphasis

[edit] Merge with software inspection

This article needs to be combined with software inspection. --Stevietheman

Nevermind. There appears to be some differentiation. --Stevietheman 18:01, 28 Dec 2004 (UTC)

[edit] Initial development phase

What was planned for the (currently nonexistent) entry initial development phase which is linked here? TalkAboutQuality 21:39, 26 September 2006 (UTC)

[edit] Code review bias

This page is very pro code review. Whilst code review by the community is a key element of open source production, line-by-line code review is not considered an efficient method of defect removal in closed source projects. A likely reason for the disparity is that paid programmers would find this kind of process laborious and boring, whereas an interested third party looking at an open source project is likely to be more focused. DanielVale 02:54, 7 November 2006 (UTC)

I would say instead that it's biased against code review. The "criticism" section is longer than the "examples" section. Furthermore, even if code review is not the most efficient method of finding defects, my personal experience is that it is good at finding code which is not well-written, and improving the structure makes future maintenance easier and less risky. This web page lists several articles supporting the efficacy of code reviews. Once I pass my next deadline, I will take a look at the articles on both sides and see what I can do to expand and improve this article. (I will note here my personal experience that code review is an effective way of finding bugs that are unlikely to be discovered through validation (particularly in extremely complex systems, where it is not practical to test all paths through the code.) Matchups 15:13, 15 February 2007 (UTC)

[edit] "Idealistic wording"

This diff removed "idealistic wording" which previously stated that code review had improved certain projects and replaced it with a statement that it is claimed that code review improved the projects. The revised text claims that it is impossible to tell with certainty that code review improved the projects, as they were only implemented once and thus there is no means of comparison.

I disagree. Having performed many code reviews, I know that the changes I have proposed have improved the code, and I am confident that if any uninvolved person had looked at the before and after versions, they would agree. There's no need for an external control; these two versions of the project are adequate to demonstrate the value of code review.

However, I do agree with Derek that there was a problem with the article, as the articles on the two purported example projects do not mention "code review," much less provide any justification for the claim that code review has improved them. I believe that what should be done is to find RS's with specific documented examples of projects which have been improved by code review and use those in this article. We should also remove Blender and Linux as examples, unless somebody with knowledge of those projects is able to edit their main articles to add a discussion of code review. Matchups 16:43, 8 July 2007 (UTC)

[edit] Facts and figures from research

When visiting this article, I expected to find reference to the research actually performed in the area and the key metrics that the different studies and experiments came up with. I my humble view, it's less interesting to hear that code review is either good or bad, compared to e.g. a table with the different studies' defect rates to conclude that an hour spent means 15 bugs dead. To me, it's obvious that eye balling the code means finding defects, means a chance to remove defects, means more stable code. The main issue to me is under what circumstances is code review the better spent hour if I want to spend an hour to make the code more stable (compared to testing, or even refactoring).

[edit] Dubious emphasis

The article seems to be focused on code review as a means of finding "defects". As a 25-years-experienced developer, I would say that is only a secondary purpose of code review. Code review is largely about honing a uniform coding culture within an enterprise, about making code more readable, etc. That is to say, it is not at all a substitute for testing: it is much more tied to the art of programming than the science of programming. - Jmabel | Talk 19:35, 25 February 2008 (UTC)