This design studio helps you understand the different types of code reviews and inspection processes, their benefits, and how to conduct them.
As with every design studio, there are two parts:
You will need to perform the following four tasks to prepare for the Basic Git Design Studio:
Complete the pre-class readings to understand what a code review is and why it is useful. You will learn the types of formal and informal inspections/reviews, their strengths and weaknesses, and the steps involved.
Determine the role you will play during the inspection in conjunction with your teammates. Here's one way to pick the roles:
This design studio will use groups of 3, so whoever has the Moderator role is also assigned the End User inspection role. The other 2 people in the group each have only one inspection role.
Moderator: person who will keep the meeting focused and moving, logging defects and only allowing discussion to the point that the maintainer understands the issue - NO PROBLEM SOLVING!
End User: person using the application (e.g., the person chatting or the administrator of the chat server) who has no idea how it is written. What kinds of input and output are expected based on the the test cases given here? How are these implemented in the code - is there sufficient information for the end user to figure out what is expected of them or to help them if something goes wrong?
Maintainer: person who has inherited this code and will have to add features to it. Review the code from this point of view: you have to be able to repeat and correct bug reports turned in by users, and no doubt have to add features to the program - speculate on what kind of features may be requested in the future and think about ways the existing code might make adding them easier/harder.
Tester: person who gets the code to test. Assume that anytime you get the code it compiles. What kinds of tests do you need to create, based on the code. Often the testing group runs all tests and testers have to decipher all the test output to figure out what happened and which developer needs to fix things.
Review the design of the OCSF framework and application presented in class in slides 7-20 of this slideset.
Here is a checklist provided for each role. Use the checklist associated with your role to find problems with the code files ClientConsole.java and EchoServer.java. Although we will only inspect these two files, their classes are both subclasses of abstract classes. It is often necessary to look at abstract superclasses to find problems. Thus, we ask you to study the relevant parts of AbstractClient.java and AbstractServer.java as you prepare for the in-class inspection.
Your job is only to find problems, NOT figure out how to fix them. Fixing problems is up to the owner of the code to do later.
Print the listings, and make notes on them regarding the kind of problem you found, and file name and line number where you identified it. You will need these listings for the design studio. Bring them to class on Monday, September 12.
If you find other problems not on the checklist for your role, but they are problems that you think a person who is really in your assigned role might run into, then note these as well.
If you find problems that are not associated with your role, you can note them, but only bring them up in the design studio if no one else mentions them.
Take the Canvas quiz called PreQ2 by Sunday, September 11, 11:59 PM. (5 points)
You will use the logging sheet found here. The instructor will print out copies for each team.
Participate in an inspection meeting with your project teammates to log defects in the given files.
Put the names of each person in your group who participated in the inspection on the log sheet, along with the role they used to inspect the code and the time they took to prepare for the inspection.
Turn in the log sheet at the end of class. (10 points)