On Friday, we will have a short code review session, looking at your web crawlers. For this session, each group will meet with the other groups at their table to discuss each group's code. We will spend most of class Friday on this exercise, plus a short all-class discussion at the end.
Important: Send your code to the rest of your group as early as possible on Wednesday. Make sure everybody has your source code with plenty of time to study it.
Make sure there is at least one laptop in class per table on Friday.
Read each group's code carefully. Once you have read the other group's (or groups') code, apply the same type of reading to your own group's code.
For each group you are working with at the code review, write down:
Make sure to write your notes in a way you would be willing to hand over to the other group. In particular, make sure your notes are legible, constructive, and polite.
Thorough testing isn't the point of this exercise, but you'll want to try running the programs a little bit.
Each team takes a turn being in the spotlight. Plan for about 10 minutes per team (with the likelihood that some discussions will spill over to 12 or 15).
At the start of each team's turn, one of that team's members should show their code on screen and be prepared to scroll to requested portions of the code. (e.g. somebody might ask "can we look for a minute at the main() function?").
When it's your team's turn in the spotlight, your job is to listen and answer questions. Resist the urge to give explanations for why you did X or Y unless explanations are requested. You'll get a chance to revise and explain in your final product.
When you are providing feedback to another team, your goal is to provide useful feedback. Feedback tends to be more useful if it is presented in a tone that doesn't make the recipient defensive, so be nice. (This is actually pretty easy. It's a simple, day-to-day application of the golden rule, and all of you are nice people.)
Sometimes, you might not have a lot of ideas for improvement of the code (maybe the other team's code is better than yours...that happens often). In such cases, just giving a clear idea of what you found easy to understand and what you found confusing would be helpful.
When the session is over, the team giving feedback should hand their written notes to the team being reviewed.