Communication Lab 12
Code Walkthrough

Due: Not Turned In

Today's activity is a split exercise; programmers and designers will be working on different activities. For the designers, we want you to start working on the Game Manual which is due this week. See the instructions for this document, though we do have some pointers below.

For the programmers, however, we want you to hold a code walkthroughs. These are an important part of the software engineering process. As your group gets more an more used to your current software design decisions, everyone has a harder time seeing the problems. A code walkthrough allows a reviewer with fresh eyes to look at what you have done. The reviewer can tell you whether the code is understandable, and point out possible design problems.

Code Walkthrough

The code walkthrough should include everyone who has written any code on the project. Only if you have no understanding of the code are you free to move on to the game manual. We will pair you with another group for the code walkthrough. You will each present your code to each other. In addition, we will make sure that every pair has a dedicated programming TA with it at all times, in order to facilitate the discussion.

Preparing for the Communciation Lab

This communication lab is a little different from ones in the past that you must come prepared a head of time. In particularly, you need to bring two things.

• A print out of your dependency diagram (nothing else) from your architecture specification.
• A snapshot of your code either on a laptop or on one of the lab computers.

Neither of these items requires that you create anything new for the lab. Your snapshot can either be the current state of your repository or your submission for technical prototype. Your dependency diagram can be the one you submitted, though if you have made changes to the architecture since my comments before Spring Break, you may want to bring an a new version of this diagram.

Organizing the Walkthrough

Each group should take turns doing a walkthrough. In the time alloted, that means 20-25 minutes per group. The group making the presentation should have a single presenter by the computer with the code, while the reviewing team gathers around. If you want to swap out presenters during the walkthrough, that is okay. However, it might get crowded around the computer, so make sure that the reviewers can always see the code.

At the start of the presentation, hand out your dependency diagram to the other team so that they can look over it while you walkthrough the code. Then your presenter should show off the major classes in your code (e.g. the ones that correspond to those in the dependency diagram, not the minor classes like the North-East-South-West enumeration that you did not bother to write down). We recommend that you show off the classes in the following order.

• The root controller class
• Any controller subsystems (e.g. specialized controller classes)
• The primary model class(es)
• The primary view class(es)

Your presentation should show how they all fit together.

Reviewing the Code

While one group is presenting their code, the other group -- the reviewers -- should be frequently making comments and asking questions. In particular, the reviewers should ask themselves the following:

• Is the code organization understandable?
• How easy is it to break up the work among several people?
• How extendable is the software architecture?
• Do the class relationships match the dependency diagram?

We do not necessarily want the reviewers to ask the questions above to the presenter. Instead, reviewers should ask questions that help them form their own answers to the questions above. And if there answers indicate problems with the architecture design, the reviewers should point that out to the other team.

Game Manual

You should refer to the instructions to see how to create your game manual. We suggest that you start with an outline of what your game manual should look like. First, create a table of contents. Write down exactly what will appear in your manual, and the role that each chapter serves. If it is a particularly long chapter (e.g. your game has a lot of gameplay elememnts, and you need to describe them all), then you should further break it up into sections.

For example, here is a very standard way of breaking up a game manual.

• The systems requirements for your game.
• How to install and uninstall your game.
• An outline of the basic objective in your game.
• Basic instructions on the controls of your game.
• Game Credits

After you have done this, you might want to write a single paragraph describing what you plan to write about in that section. Alternatively, you can get started filling in that section already. It is up to you, but we suggest you use the time wisely.

Submission

There is nothing to turn in for this communication lab, neither for the walkthrough nor the game manual.