In-Class Reviews
You must be prepared to explain your code and to review other people on short notice. You will typically get 2 to 12 hours of advance warning to explain your code to a panel of your peers. Code reviews are not fancy presentations and they are not about awing your audience with how it functions. It’s for your teammates to understand the code when they take over and need to fix problems.
Since everyone is working on the same problem, you are always ready to review the design decisions and implementation ideas at a moment’s notice. There is no need to prepare.
Introduce yourself together.
Tell the class which language you are working in.
Remind the class of the task that is the focus of your presentation.
One of you will share the screen and present.
Run your test script to illustrate the state of your software.(Optional)
Present the code in a top-down fashion (*).
Explain code that is visible to the audience. Don’t scroll while you speak.
If you chose an unusual programming language (for example, Haskell, Racket, Rust), explain unusual features as you go.
If your IDE supports it, turn on line numbers and use them during your explanations.
Consider highlighting code that you wish to discuss in detail.
The presenter (and only the presenter) must be prepared to respond to the panel’s questions at any time. The instructor may jump in. Questions from the class will be managed by the section’s TA.
The instructor will ask the pair to switch roles when appropriate.
The second presenter is free to choose what to present next: resume where the first one left off; restart from the top; or proceed to a different place in the code that deserves attention. As your code base acquires complexity, the second presenter may even choose to revisit old portions of the code base. No matter what, the second presenter must observe the above guidelines in the same spirit as the first one.
The primary goal of a code reader is to help the presenters find problems in their approach to achieving a particular milestone. Like presenters, a panelist should use the literal design recipe to evaluate local pieces of code (classes, methods, functions) and the generalized one for complete components.
(*) Top-Down means that you explain how you organized your Program to solve the problem. For each module/function or class/method bundle, you follow the design recipe to explain its purpose. Start with the main module or class and within those with the main function. Then work your way to less important elements from there.