There are many excellent points above by both kvale and dragonchild. Here is my two cents for what its worth.

There are a number of ways to go about code review, and I have participated in each kind and found they all have their benefits and drawbacks.

  1. Group Code Review

    This tends to get really boring, really fast (as most meetings here in the corporate world do), especially if it is too detail oriented. However, I have seen a lot of value (given the right mix of people) when more high level elements of the code/implementation are discussed and debated in this format. Now discussing code at too high a level, I would guess, would not work in your world since it would basically be a discussion about your assignment. However, if you stick to how it is implemented, and not what is implemented it may work out. It could also be thought of as a post-assignment exercise if that helps.

  2. One on One Code Review

    This is personally my favorite and have proven to me to be the most fruitful. The basic idea is you sit down with someone and explain your code to them while they ask probing questions about why you did this, and how you did that, etc. A lot of times, your best revelations come from the act of explaining your code too. I have also seen this work with more than one other person as well, although sometimes that degrades into too much side discussion.

  3. Private Code Reveiws

    You give me your code, I go somewhere and review it. This is what you seem to be proposing above. This method can be really valuable, but tends to take a lot of time and many times requires the reviewer to really know their stuff. To be honest, I have only ever known a few people in my career (PerlMonks not included) whom I have felt doing this with was worthwhile.

As I said, I have seen all three of these approaches work, and all three of them fail miserably. The single most important element to success though, is an open mind and a willingness to take and give criticism (preferably constructive) on the part of all involved. Nothing will derail this process sooner, than a reviewee who can't take a little criticism or reviewers who are afraid to speak up.

-stvn

In reply to Re: Advocacy of code reviews: how the heck do you do it? by stvn
in thread Advocacy of code reviews: how the heck do you do it? by FoxtrotUniform

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.