Slashdot Mirror


Code Reviews- Do They Really Exist, In Practice?

dante101vr2 asks: "While working in the programming field I have heard a lot of mention to doing code reviews, however I have yet to see one occur. Along with my job, I have also talked to a number of others throughout the IT community who laugh when they hear mention of a code review, claiming that there is not enough time in the day. My question to you is, do code reviews exist, and are they a good tool or are they just time consuming?" For those of you who do have normal code reviews, what small things do you do to make the whole process go along as painlessly as possible?

1 of 36 comments (clear)

  1. Rare, but they can work very well. by Lumpish+Scholar · · Score: 5

    Code reviews are the practice most univerally praised and most rarely carried out.

    My first exposure to something like code reviews was writers' workshops; everyone submits a poem, story, whatever, and then everyone critiques everyone's works. From this, I learned the first rule of both writers' workshops and of code reviews:

    REVIEW THE WRITING, NOT THE WRITER

    Being reviewed is tough on the author's ego; spare him or her as much as you can. If everyone gets a turn in the hot seat, they'll learn the difference between flamage and constructive criticism.

    Here's the second rule: People hate performing less than they hate preparing for code reviews. It's heresy, but I've had a lot of luck with zero-prep code reviews: Everyone shows up, gets a printout, and away we all go. It can take a lot of time in the review, but the total time spent is smaller (and, IMHO, more effective). In reality, people skip the preparation; why not plan for it?

    Third rule: Reviews identify problems, not solutions. You don't have to know a better way to know something's wrong.

    Fourth rule: The author is there to learn, and to answer questions, not to be defensive.

    I brought code reviews into the small startup I joined a few years ago. Final rule: everything deployed to production gets reviewed. It worked; not only did my co-workers accept it, but at least one of them, when he left for another job, got people there to do code reviews the same way.

    Code reviews aren't just for finding bugs; they're for improving the quality of the code, for whatever your local definition of "quality" is. I've always considered maintainability to be fair game.

    My current project has a fairly rigid process, put into place long before I arrived. Here, they do desk checks and call them "reviews." It's not as good, but it's better than nothing.

    --
    Stupid job ads, weird spam, occasional insight at