WDD 430: Web Full-Stack Development

W05 Team: Code Review

Overview

This week you are reviewing your teammates' real contributions to the team web application project. You will review a teammate's Pull Request (PR) on the team project repository. Your feedback should help your team improve code functionality, quality, and maintainability. Work as a team to ensure all PRs receive timely, meaningful reviews. By the end of this activity, you should be able to evaluate a Pull Request against user-story acceptance criteria, verify implementation quality, and submit clear, actionable feedback in GitHub's review workflow.

Activity Instructions

Teammate review assignments

As a team, create and confirm your Pull Request review assignments. At this point in the course, teams will control reviewer pairings for Pull Request reviews. Your team owns the pairing plan and each member is responsible for reviewing assigned PRs ensuring that every Pull Request receives a timely, meaningful review from a teammate.

• Each team member should review at least one teammate's Pull Request this week.
• When appropriate, assign a second reviewer to a Pull Request that is high-risk, complex, or blocked.
• Avoid reciprocal pairs when possible (A reviews B and B reviews A) to increase cross-team feedback.
• Post the final reviewer-to-Pull Request assignments in your Microsoft Teams channel, including reviewer name and Pull Request URL.

Locate your teammate's Pull Request

Open your team project GitHub repository and find the Pull Request assigned to you in your team's pairing plan.

• Use the Pull Request title, linked issue, and branch name to confirm you are reviewing the correct user story.
• If you cannot find their PR, contact your teammate in Teams immediately.

Review the Pull Request

In GitHub, open the Pull Request and use Files changed to perform a structured review. Focus on whether the code satisfies the user story and supports the team architecture.

1. Start with intent: read the Pull Request description and acceptance criteria before touching the diff.

   The diff is a comparison of changes between two versions of a file. In GitHub, you can view the diff to see exactly what has been modified.

2. Verify behavior: pull the branch and confirm the feature works as described — don't approve code you haven't run.

   git fetch origin
   git checkout -b feature/teammate-review-branch origin/feature/teammate-review-branch

3. Comment in context: use GitHub's line-level comments so feedback is anchored to the code, not abstract.

   Review expectations

   • Review the code and product behavior, not the person.
   • Prioritize issues by impact: correctness, security, accessibility, performance, maintainability.
   • Tie feedback to the user story acceptance criteria and sprint goals.
   • Suggest concrete fixes where possible, not just criticism.

   Review comment labels

   Use these as prefixes in your GitHub comments:

   • [blocker] — Must be resolved before merge
   • [suggestion] — Recommended improvement, not required
   • [nit] — Minor style or preference, author's call
   • [question] — Asking for clarification, not blocking

   Code Review Checklist

   Use this checklist to guide your comments and final review decision.

   1. User story alignment
      • Does the Pull Request clearly reference the assigned sprint user story or issue?
      • Are the acceptance criteria addressed completely?
      • Is the Pull Request scope focused, or is unrelated work mixed in?
   2. Functionality and correctness
      • Does the feature work as described in the PR?
      • Are edge cases and validation handled?
      • Are there regressions in existing behavior?
   3. Code quality and maintainability
      • Is the code readable and logically organized?
      • Are names, component boundaries, and abstractions clear?
      • Is duplicated code avoided where practical?
   4. Next.js/TypeScript practices
      • Are server and client boundaries used appropriately?
      • Are types explicit and safe (minimal any)?
      • Are async operations and error states handled cleanly?
   5. Accessibility and UX
      • Are semantic elements and labels used correctly?
      • Is keyboard navigation considered for interactive elements?
      • Are loading, empty, and error states understandable to users?
   6. Testing and verification
      • Did the author provide evidence the feature was tested?
      • Can you run and verify the changed behavior locally or in preview deployment?
      • Are critical paths covered with checks or tests where applicable?
   7. Pull Request hygiene
      • Are commits and Pull Request description clear enough to understand intent?
      • Are screenshots or notes included for visible UI changes?
      • Are merge blockers clearly identified before approval?
4. Summarize once: consolidate your findings into a single review decision rather than a stream of individual comments.

Submit your review in GitHub

1. Click Finish your review in the PR.
2. Select the appropriate review type:
   • Approve if acceptance criteria are met and no blockers remain.
   • Request changes if blockers prevent merge.
   • Comment for feedback that does not block merge.
3. Post a short summary comment that includes:
   • What was reviewed (user story/issue number)
   • Top strengths observed
   • Any required fixes before merge

Submission Instructions

Return to Canvas and submit the code review survey. Be prepared to submit the URL of your submitted GitHub Pull Request review in the survey along with a short summary of the key feedback you provided.

You will also submit the URL of your submitted GitHub Pull Request review in the Team: Project & Code Review assignment this week.