Critique 3
Code Walkthrough

Code walkthroughs 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.

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.

The code walkthrough is the primary purpose of today's (and the last) critique. Obviously this is a programmer-centric critique. We do have an alternative exercise for designers as well, however.

This critique will take place in Discord, just like the level design critique. Once again we will use the playtesting channels to pair up groups.

Preparing for the Critique

As with most critiques, you need to be sharing your screens. You need to come prepared with the material that you will share. In particular, we want you to be ready with two things:

• Your dependency diagram (nothing else) from your most recent architecture specification.
• A stable version (snapshot) of your code to display.

Neither of these items requires that you create anything new for the critique. Your snapshot can either be the current state of your repository or your submission for pre-beta release. Your dependency diagram can be the one you submitted, though if you have made changes to the architecture since my comments over break, you may want to bring an a new version of this diagram.

Walkthrough Format

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 be the ones sharing the screen. If you want to swap out presenters during the walkthrough, that is okay. We will leave it up to you whatever you are most comfortable with.

While you can share your dependency diagram on the screen, we recommend sending out a link to a PDF. That way the other team can have it ready to look at while you walkthrough your code.

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.

Designer Activity

Code walkthroughs are very programmer-centric. So what should the designers do? Designers are welcome to participate in the code walkthroughs, but alternatively you can have animation critiques as well. For this critique you should have

• A spritesheet of a complete animation
• A demonstration of this animation in action (either a GIF or in the game)

Designers should pair off with the same group that the programmers have paired with (though in the opposite playtesting channel). One group should present an animation and the other group should comment on it. Feel free to critique more than one animation. When this is done, the other group should present their work.