This is not the current offering of the course. You may want the next offering at https://ucsd-cse15l-f22.github.io/, or scroll down for the winter 2022 material.

Week 7

Week 7 – Code Review

TODO

  • Quiz 7 - Due 11:59am February 16, 2021

Notes from Class

Monday 1pm

Monday 2pm

Monday 3pm

Lab Tasks

In this lab, you will review another group’s code to give feedback, find new bugs, and learn from each other.

The overall plan for lab is:

  1. You will get a link to a repository from another group, download and work on the code for 30-40 minutes.
  2. Half of your group will meet with half of that group to ask questions and discuss; the other half of your group will stay to answer questions from a group that’s reviewing your code.
  3. You’ll regroup with your entire group to finalize specific feedback on the code you are reviewing.

Part 1 – Initial Review

Your lab tutor will provide you with a link to a repository for another group.

Clone it, and complete the following tasks. For each, document it in your notes file:

  • Run their tests. What was the easiest way to run their tests? What commands did you use? Did you have any trouble doing this?
  • Does your group have any tests that they don’t have? Add them and run them. Do they pass? Make a commit with the newly-added tests.
  • Do they have any tests that no one in your group has? Make a note of which ones in the notes document.
  • Choose an example input and trace through the code with that input. In your trace, build a table with a row for each iteration of the loop (or each loop, if the group added multiple), showing the value of each variable at the beginning and end of the loop. You can try doing this by hand, but it may be much more effective to do it with print statements!

Your goal should be twofold:

  1. Come up with at least two issues to report (you’ll do this as actual issue submissions later). For each, include the failure-inducing input and the symptom; save it in your Google doc for now. For at least one of the issues, try to fix it.

  2. Come up with questions for the group as you do this. For example:

    • Are you unsure why a particular condition works the way it does?
    • Do you think there is a bug in their code?
    • Are you unsure what the purpose of one of the variables is?
    • What are some missing test cases, and why are they important to include?

Write at least 3 questions down in your Google Sheet. You are going to ask these questions to the other group.

Part 2 – Discussion

The lab leaders will help reorganize your groups so that half of your group meets with the group whose code you are reviewing to ask questions, and half of your group meets with the group that is reviewing your group’s code.

Ask the questions you wrote down and write down the answers, and discuss interesting differences you’ve noticed between your code and the other group’s.

Part 3 – Review, Issues, and Pull Request

Next, you will use what you learned to make suggestions for improvements to the other team’s repository. Submit the two issues you came up with earlier as Github issues.

Take the time to nicely format these and make them helpful to the team you are reviewing for. Make sure across your two issues to do the following:

  • Go look at their code and link directly to a line you think could be changed or added to in order to fix an issue (you can click on line numbers in Github to get a direct link to that line)
  • Include a code block with a test file you wrote – it’s important to put it in a code block and not a screenshot so they can easily copy-paste it!
  • Include a code block or screenshot of the test failing so you can easily describe the symptom.
  • For at least one of the issues, make sure to suggest a fix.

In all of this communication, remember to be polite, professional, and focus on giving detail and clear writing. A huge part of the job of a working software professional or researcher is accurately communicating about code and system behavior. This lab is practice in that, and pull requests/issues are one way professional engineers do this all the time.