Code Review Checklist

code-review-checklist.md

Pair-to-Pair Code Review

5 mins

• Get together with your group and send a link of your team's GitHub Repo to the pair that is reviewing your project.
• Look over this guide with your project partner and highlight the pieces where your team can use assistance/you would like your reviewers to take a closer look. Fork this gist and send the forked copy over to the pair reviewing your code.

45 mins

• Follow the instructions to clone down the repo you are given and start reviewing the codebase. Take notes for written feedback.

5 mins

• Come back together in your larger group. This time should be used to have an in-person discussion about the feedback. Send your formal written feedback as a gist/document to the pair and your instructors.

Review Guide

While reviewing the code, ask yourself the following questions:

CODEBASE

• Does the code work? Does it perform its intended function, the logic is correct etc.
• Is all the code easily understood?
• Does it conform to Turing's Style Guide? These will usually cover location of braces, variable and function names, line length, indentations, formatting, and comments.
• Is there any redundant or duplicate code?
• Does the code follow the principle of single responsibility?
• Can any global variables be replaced?
• Is there any commented out code? Any console.logs?
• Do the names used in the application convey intent?
• Do tests exist, and are they comprehensive?
• Do unit tests actually test that the code is performing the intended functionality?
• Does the repo have a .gitignore file? Is there a .DS_Store file or node_modules directory committed that shouldn’t be?

README We don't have a README yet.

• Does the README follow the conventions we discussed in class (i.e. Abstract listed first, install instructions second, everything else listed after)
• Is there a link to the DTR for the team available?
• Is there a wireframe for the project available?
• Is there anything that is confusing or hard to understand with what is written?
• Does the README do a goob of showcasing this project? If you were a random human who happened to come across this project, would you explore it further based on the current state of the README?
• What suggestions would you make for making the README better?

GITHUB/ISSUES/WORKFLOW

• Are issues being used to keep track of tasks, enhancements and bugs?
• Do the titles/descriptions of the issues provide all the relevant/necessary details for the issue? Would you be able to jump right in and assist?
• Are other strategies being used to keep track of issues (labels, milestones, assignments)?
• Is there effective communication happening in PRs outside of working school hours?
• Do the PRS follow the flow that we discussed in class?
  • Summarize the changes that you made.
  • Give the reason WHY you made those changes
  • Ask for any insights

Feedback

You will be writing a formal piece of feedback (with your partner) to give to the team whose project you reviewed this morning. Use these questions as a guide; however, you are also free to give additional project feedback on anything that may have been overlooked with the questions listed above. Feedback is due by the end of the session. Please save your feedback as a file or gist and send it to your instructors and the pair. Remember to follow the feedback guidelines you went over as part of your professional development in Mod 1.

• Does the code work? Does it perform its intended function, the logic is correct etc.
  Submitting answers was not working, but I saw you have an issue for that on GitHub. So it's good you are aware of what still needs to be accomplished.

I was unsure of how the findMatchingCard method in the clue class works. In the find method, it checks if clue.categoryId === cat, and I though categoryId was a number. And I thought cat was a string because in the event listener function for $('.category'), cat = category.toLowercase().

• Is there any redundant or duplicate code?
  I think updateCategories() in domUpdates can be made into a loop using template literals for the indices so you don't have to write similar code four times.

• Do the names used in the application convey intent?
  I think updateCategories() in domUpdates can be given a more specific name. updateCategories could also be a name for changing the round 1 categories to the round 2 categories. Maybe something about how it changes it out of camelCase could be added to the name.

• Do tests exist, and are they comprehensive?
  You still need tests for Clue, DailyDouble, and Player. The tests you have for Game and Round are really good. The first it block in Rounds-test says 'should have a categories property which is an empty array', but the test expects the length to be 4. I think you may have forgot to change the string to reflect the test.

• Do the titles/descriptions of the issues provide all the relevant/necessary details for the issue? Would you be able to jump right in and assist?
  The issue titled "Update player score based on answer validation" has a very short description. I think you could pseudocode how you plan on achieving that functionality. And you could make each of those steps a check box too.