Code Walkthrough

The purpose of today’s class is to hold a code walkthrough These are an important part of the software engineering process. As your group gets more and 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.

Another advantage of the code walkthough is that it gives you a chance to compare your code to your architecture specification. You might think that the specification was an accurate representation of the code that you have written so far, but an outside observer might have other ideas.

Code walkthroughs are clearly programmer-focused. While designer are free to participate, we have constructed an alternate activity for them.

Table of Contents

Code Walkthrough

This class is closer to a presentation than a previous communication labs in that you must come prepared a head of time. In particularly, you need to bring two things.

  • Several print-outs of your dependency diagram (nothing else) from your architecture specification.
  • A snapshot of your code on at least two laptops so that everyone can look at it.

Neither of these items requires that you create anything new for the discussion. Your snapshot can either be the current state of your repository or your submission for alpha release. Your dependency diagram can be the one you submitted for document revisions. However, if you made more recent changes, you should bring the new version.

With that said, please bring several copies of your dependency diagram, so that you can pass them about the other group. Four or so to share should be sufficient.

Walkthrough Format

We will pair groups with each other. You will each present your code to each other. 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 their answers indicate problems with the architecture design, the reviewers should point that out to the other team.

Designer Activity

Code walkthroughs are largely a programmer activity. The designers do not typically get anything out of them. But do not worry, we have a similar activity for the designers as well. In this case, we are going to be focused on animations.

For this activity, you need to bring animations for one or more characters. Preferably you should pick a character that has more than one animation. But if you game does not work that, animations from different characters will work as well.

In addition, you should have a list of all of the actions that each (animated) character can do. You should have these from the gameplay specification. Unlike the programmers, we are not asking you to bring copies of the gameplay specification to share (as it is unlikely these actions are summarized on a single page). But it would be a good idea to make this document available to the reviewers.

Review Format

Each group should take turns doing a presentation. 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 animations, while the reviewing team gathers around. The animations should be visible in action, not just sprite sheets. But we do not require that you show the animations in game if they are not ready yet.

While looking at the animations, the reviewers should ask themselves the following questions

  • How smooth and natural looking are the animations?
  • Do the animations do an effective job at establishing a character?
  • Are all possible actions of this character covered by the animations shown?
  • Can the character smoothly transition from one animation to another?

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. In particular, one of the things to look for is if the team will need to change animations or add intermediate, transitional animations.Acciden