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.

This is clearly a programer-focused lab. Designers may participate in it if they wish. However, if you do not feel that this is a productive usage of designer time, we recommend that you start working on the Game Manual. This is the last official document for the course, and is due in another week.

Walkthrough Format

The code walkthrough should include everyone who has written any code on the project. As with previous critiques, we will pair you with another group in Discord. You will each present your code to each other. If possible, 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 copy of your most recent dependency diagram (nothing else)
  • A snapshot of your code as of alpha release

Neither of these items requires that you create anything new for the lab. Your snapshot can simply be the current state of your repository.. Your dependency diagram could be the one you submitted in your architecture specification. However, for proper feedback, it should accurately represent the current state of your software.

Organizing the Walkthrough

Each group should take turns doing a walkthrough. In the time alloted, that means 20-25 minutes per group. The presenting group should make the dependency diagram available for download in the playtesting chat. The other team will use this for reference as the presenter walks through the code.

Once everyone has a copy of the dependency diagram, 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.