LarynaB / Peer-Code-Review-Checklist

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Lambda School Peer Code Review Checklist

Code review is the time to catch issues and help students who don't understand concepts from the day or week. Students can use the peer code review as an opportunity to push and challenge each other technically. While students should feel free to ask questions, they should also be ready to explain and defend their code.

For Peer Code Reviews, each person in the pair will take turns reviewing and being reviewed.

Part I - Review Projects

At a minimum, review the code for the following:

  1. Each project is pushed to GitHub with clear, detailed commit messages.
  2. Each project is feature complete and works as expected.
  3. There are no exceptions or warnings in your console or Chrome Developer Tools.
  4. Code follows consistent naming conventions, language idioms, and style.
  5. Code is written by the student. If the code was written while pair programming, the student being reviewed should be prepared to distinguish the aspects which they worked on, but also be able to explain what their pair programming partner wrote.

Part II - Review Objectives

Objectives from the Training Kit are written in our 'Student can...' format, and reflect the skills that students are expected to demonstrate in their assignments. Using the Peer Code Review form, review each competency or objective in each sample of code, to determine an overall rating (0-3).

  1. Ask to see examples of each objective in the project.
  2. Ask the student to explain the code and how it demonstrates their mastery.

Rating Scale

Score Description
0 Incomplete
1 Did not meet expectations, obvious bugs, missing functionality, took longer than expected, etc
2 * Met expectations defined in the project in the given time
3 Went above and beyond, completed at least one stretch goal, or otherwise added upon the expectations of the project

* 2 is the default score. A 3 should only be awarded when the student has demonstrably mastered the objective.

NOTE: Ratings are not grades, and there are no GPAs. Students and their reviewer should come to a consensus rating to understand where the student excels, and where the student may need some extra attention or help.

Part III - Make a Plan

Focus on objectives where the student did not meet expectations.

Make a plan. Focus on fixing deficiencies first, then focus on mastery, stretch goals, or other advanced work.

Plans should include videos, resources, or exercises the student will complete in order to improve their mastery of the curriculum.

Part IV - Address Any Additional Needs

If there are any follow-up questions about a student's code that should be discussed with a project manager or instructor, please make note in the Peer Code Review form: https://airtable.com/shrVBzrhkcT6GqExr

About