GP #06: Peer Review

Canvas will have group assignments. If for some reason you complete a group assignment and not all assigned members participate, please add a hand-in comment explaining the situation. You should make a reasonable attempt to convene all group members in one sitting, but you should not hand in late because one group member was unresponsive or missed an arranged meeting. If you have concerns on this point please e-mail the course staff to explain the situation. (This applies for all future group assignments as well.)

We suggest, but do not require, that you use Google tools for real-time collaboration (in this case a shared spreadsheet for recording review results as you go): https://www.cmu.edu/computing/services/comm-collab/collaboration/google-drive/index.html

Do a peer review on the following code: OpenBSD qsort version 1.10. (Note that this is an acrobat file so everyone will have consistent line numbers to work with.)

You'll be using an industry-oriented peer review checklist for this review. (This is NOT the same as Project 3/4, but it is the review checklist you'll be using later in the course for your projects after Project 4.)

Spend a few minutes (no more than 5 minutes) getting general familiarity with the file so you more or less understand what's going on. This is a QuickSort implementation, and hopefully you've seen that algorithm before somewhere, but that is not essential for the code review.

Assign the following roles within your group:

Methodically go through the code starting at line 83 using the following procedure:

  1. The review leader identifies a chunk of 1 to 10 lines (typically 4-5 lines) to focus on.
  2. Each reviewer looks ONLY at the assigned code chunk and looks at EACH assigned item one at a time.
  3. A reviewer finding a problem states exactly this content in exactly this order: Rule #, Line #, brief description; review leader writes them down in the review log.
  4. When all reviewers have completed their checklist, review leader asks "anything else?" Reviewers can spend a brief moment saying things not in their assigned item list.
  5. Review leader returns to step #1, starting the next chunk

Stop when you've spent a half hour or recorded 20 defects -- whichever comes first. Hand in the review file. This is not a race; and it is MUCH better to be thorough than fast. So the fewer chunks of code you look at to find the first 20 defects, the better you are doing.

Supplemental Material:

RUBRIC: