Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit

SOFT2201/COMP9201

Week 8 Tutorial

Code Review

Code Review

Reviewing code is something that is probably 1% theory and 99% practice and experience. So for the majority of this tutorial we will simply be reviewing code.

There are a few key rules to remember when it comes to reviewing code:

• Code is written by humans (or written by code written by humans, etc., etc.).  You should always remember that there is a person behind the code you are reviewing. Constructive, polite criticism that addresses issues in the code, not issues in the author - this is the most important requirement

You will not catch 100% of everything, and it is inefficient to try

• Code reviewing is difficult - you will burn out on large amounts. Divide and conquer and your reviews will improve

• Reviewing code is a separate skill to programming - being good at one helps the other, but isn’t the same as the other. Practice both.

For our tutorial this week, we will be playing a little chair roulette. Please use Ed workspaces for all your tutorial work today under the instructions of your tutor.

To support this as a process with all students in the tutorial changing task at the same time, we need to drive things a little faster and harder than in previous tutorials - so there are time limits given for each step of each question.

Question 1: Informal Review: Pair Programming

You will be given 50 minutes in total for this question.

Code review normally requires a minimum of 2 people (you can review your own code, but this is not nearly as effective). So you are going to be allocated to a group of 2 by your tutor. Groups of 3 are also ok if the class has an odd number of people, but you will need to work that much faster to get things done. In your group of 2, 1 person will start as the Driver, and the other as the Navigator. If you are in a group of 3, you will need to rotate through these roles - don’t have 2 drivers or 2 navigators at the same time as this can lead to a Too Many Cooks issue, 1 person should be watching in silence (if you have a brilliant idea or see a horrifying bug then ask to swap roles first).

Your task is to implement a Library system.  This system should support multiple types of media (Book[Fiction, Non-Fiction], E-Book[Fiction, Non-Fiction], DVD, VHS, Video Game, etc.), and have Borrowers.  You do not need to implement a UI for this system.  The library has a certain number of each individual Media item (electronic versions i.e. e-books are infinite), these Media can be borrowed by borrowers if the library has stock, and returned.

You should implement this system using the Pair Programming development method.  The specific timetable is as follows:

 Step 1: Introduction and pairing (10 minutes)

  Go to the corresponding Ed workspace (following your tutors instruction)

  One group member creates a folder with the name of "member1_member2"

  Other group members nd and join the folder created by your group member

  You are going to do the programming under your group folder from now on

Step 2: First session (10 minutes)

Step 3: Second session (10 minutes)

 Step 4: Third session (10 minutes)

 Step 5: Fourth session (10 minutes)

At each session, you will internally swap roles with your group member. If you have already swapped roles, or you are not at a good place to swap, this is fine - but you need to ensure each group member has a chance to do both roles (again those in groups of 3 will need to work harder and faster).

Some groups will find this easier than others.  If you get the given functionality done, extend your code. You could add due dates and late fees, more types of media, a CLI user interface, or Employees.

Question 2: Semi-formal Review: Audit

You will be given 50 minutes for this question.

Wherever your code is up to right now is where it stops. Create a readme text file in your group folder and leave a quick note if you did not nish something.

Every group must now rotate to a different group’s folder on Ed workspace. Your group now chooses the group folder which is listed above your group folder in the workspace, then create a review text file inside that folder named "review_member1_member2". You will now review that group’s Library system, specifically looking for the following:

Bugs

• Poor design

• Unmaintainable code

• Style Issues

Functionality/Validation issues (these should be rare as the specification is very vague)

• In addition any instances where the opposite is true (like good design or clever solutions)

Remembering the key rules above, review the code you see. Note down any observations you make in your review text file created just now.

You will be reviewing at least 2 groups:

Step1: Preparation (5 minutes)

• Step2: Choose the group folder which is listed above your group folder in the workspace and Review for first group (15 minutes)

• Step3: Choose the group folder which is listed below your group folder in the workspace and Review for second group (15 minutes)

Step4: Return to your own group folder and read the feedback you have gotten (15 minutes)