Code reviews are an important practice in software development. While testing and coding standards compliance can be automated to a large degree using JUnit tests or static analysis tools, getting another human to read your code is still valuable. A code review tends to catch design problems or missing requirements, which automated tools miss. As a student, an informal code review will also give you practice reading others' code and expose you to other solutions to the same problem.
On Friday, you formed groups for the review. If you are in section 02 or 03, you can review your groups here. (Note that there are two sheets, one for each section.)
If you missed lab on Friday but still want to be in a group for Wednesday's lab, contact your TA by 6pm Monday to help you find a group.
Here are all the submissions for A05a:
You should review the submissions of the other people in your group. Do not review your own submission.
To review their code, answer the following questions. Bring your completed answers with you to Wednesday lab in some way, such as on paper, in a text file or email, etc.
Use the following yes/no checklist to confirm certain details of the code you are reviewing. Some of these you will be able to confirm simply by reading the code. For others, you may have to actually run/test the code. If the code fails to meet one of these requirements, add a few words about why it failed. You will want to provide this extra information to the code's author on Wednesday.
Pyramid Stack
item.compareTo(top.getData()) > 0
UsernameA05a
General:
Get together with your group and go over your reviews together. The process for this is as follows:
Each person in the group will take a turn as the author currently under review. The current Author should pull up a copy of their code so that the group can quickly refer to it as necessary. (You can bring a laptop, extract your JAR onto the lab computer in front of you, pull up your code on Tamarin, bring a print-out, etc.) The Author may optionally give some introductory comments about the state of their code, such as known problems, parts they are proud of, or parts they would like additional feedback on.
The other group members will then act as Reviewers. The group should go through the above checklist one question at a time, sharing and comparing their individual notes. This should produce a single group review. For later reference, the Author should complete a new review form that records the group's conclusions. The Author can also ask for clarification regarding the Reviewers' comments.
The point of this exercise is give the author helpful, constructive feedback regarding their code. You are also discussing the quality of the code. Some Reviewers may find defects that other Reviewers missed, or Reviewers may disagree on what counts as a defect. These are opportunities for discussion and reflection on what makes for good code and a good solution.
Pace yourselves so that every group member receives some feedback as an Author. If there is time left over, you may then help each other improve your code or fix bugs found by the reviews (if you want to).