18-642 Project 4
Page last updated 8/25/2019 (changelog)
This project gives you hand-on experience with peer reviews. In your peer
review groups, you will conduct a review of each member's code.
NOTE: in the previous project we let you skip a few
checklist items. You should use the time before your peer review to FIX all
these items. You do NOT get a free miss on those items this week.
- Please follow the handin naming convention: every filename (before the
file extension) must end in [AndrewID]_[FamilyName]_[GivenName].
- Peer review lecture slides from class
alternate peer review checklist (this has helpful suggestions for more
general embedded software, but is not required for this peer review)
- Also see the recitation handouts
- Review the course slides about Peer Reviews. Remember the following
- Inspect the item, not the author
- Don't get defensive
- Find but don't fix problems
- Limit meetings to two hours
- Keep a reasonable pace
- Avoid "religious" debates on style (While enforcing what the
Project 3 checklist says)
- Inspect early, often, and as formally as you can
- Schedule some time(s) to meet with your peer review group. Remember that
you will spend about 30 minutes per project. (You will be tempted to go fast.
If you do, likely you'll pay for it later with more bugs. Take the time to do a
good review now.)
- Conduct a review for each of the four students in your group:
- Use of the project checklist is mandatory. Issues from the alternate
industry checklist are optional. (We'll get back to those later, but for now
keep it simple.)
- If you are reviewing Alice's code, assign Alice as the scribe. Alice should
only say "OK" to indicate that an item has been recorded, or
"thank you" during the review of her code.
- Assign someone (who is not the author of the code under review) to
be the leader. Rotate this job. After one review per group member, everyone
should have had a turn being the leader. The leader is in charge of:
- Picking the next few lines of code for everyone to concentrate on
- Making sure that all issues identified have been recorded before moving on
- Making sure everyone follows the process.
- Divide the checklist up into sections and assign one section to each of the
reviewers to improve focus when looking at the code. (Any reviewer can note any
problem, but each reviewer must look at each element in the assigned checklist
portion for each section of code.) The leader can own one of the sections; the
author cannot. If you only have three people in your review group split the
list in half for the two non-authors.
- Project the code onto a surface that everyone can see at the same time.
- Fill out the peer review issue log as you perform the review. Remember, do
not fix issues as they arise!
- Refer back to the Project 3 checklist to enforce style.
- Optional: additionally, you can assign reviewers items from:
alternate peer review checklist. However, the project 3 checklist items
must also be addressed if you do this.
- Go through the code systematically -- be sure to talk about every line of
- After the review, fix all the issues found with your code. We recommend
having reviews BEFORE hand-in day to avoid a last minute time crunch.
- Answer the following questions in a short writeup:
- Your name (in case we print them out, the file name will be missing)
- Q1: Do you think the review of your own code missed anything? If so, what?
- Q2: Was there anything you think should be left out of the peer review
- Q3: Did you have any problems with your group? If so, what?
There are TWO hand-ins for this assignment.
Individual hand-in: (every student hands this in solo):
- Your ANDREWID_student_turtle.cpp file with fixes, named
- The completed peer review spreadsheet for your code including
"status" column annotations:
p04_review_[AndrewID]_[FamilyName]_[GivenName].xls. The majority of
"status" should be "fixed" but other annotations are
permissible if appropriate.
- Your writeup, named
Zip these three files and submit them as
Project04_[Andrew ID]_[Family name]_[First name].zip in the Project 4
Group hand-in: (every group jointly hands in ONE copy of
- All of your peer review spreadsheets BEFORE
any fixes have been done. Each one should be named
p04_review_[AndrewID]_[FamilyName]_[GivenName].xls, and you should batch
them together in a zip file to hand in rather than using multiple spreadsheet
tabs. We strongly suggest you hand this in while you are together as a group
immediately at the end of the review session BEFORE anything has been fixed to
avoid confusion about who was responsible for doing the hand-in or forgetting
to do it. It is expected that the "status" column will be blank.
Zip the peer review spreadsheets together into one file
one file and submit it to Canvas in the Project 4 (Group) submission as
Please do NOT put these files inside a subdirectory. When
unzipped they should not have any directory associated with the file name, and
should just unzip into the current directory. (The file name convention will
retain whose work it is.)
The rubric for the project is found here.
- 8/25/2019 4:00PM: released