In-Class Reviews

at least we
don't have to obfuscate it before we ship it

The primary goal of a code walk is to explain the problematic part(s) of your code base. So, proceed as follows:
  • Introduce yourself.

  • Tell the class which language you chose and anything that’s special about it.

  • Remind the class of the task that is the focus of your presentation.

  • Run the test harnesses and/or unit tests as appropriate to illustrate the problem(s) we found.

    Being chosen often means that your solution failed one of my tests or a test that your peers submitted. While it is good to show the JSON inputs and outputs and explain the misbehavior there, the second step should almost always be one that explains how you internalized this failure into a small unit test, because those are easier to understand than JSON tests.

    If your code passes all tests, you will skip this step.

  • Present the code in a top-down fashion. Explain your language as you go.

    If your code passes all tests, work your way from the bit picture down to the interesting new ideas. Your peers deserve to see your code organization.

    If you have a simple fix, explain it. If you don't, focus on explaining the problem, the area of code that is broken (see below), and then solicit help.

  • Be prepared to respond to questions by the class as admitted by the instructor.

  • Explain code that is visible to the audience. Don't scroll while you speak.

Top-Down means that you explain how you organized your Program to solve the problem and for each function/class+method, you follow the design recipe to explain its purpose. Start with the main function/class and work your way to less important functions/classes+methods from there.


Just in case nobody ever explained debugging in the context of systematically designed code, here are basic hints:
  • turn the failing integration tests into failing unit tests;

  • if a function/method fails its unit test, turn the failing test into unit tests for all the functions/methods that it calls.

  • eventually this "divide and conquer" method locates the bug in a narrow slice of your code. Focus on this slice for bug fixes.

If your methods "collude" to achieve a common goal, the "slice" may consist of two disjoint regions of code. You will need to understand the logic that connects those and figure out the fix from there.