WDD 430: Web Full-Stack Development

W06 Team: Code Review

Overview

This week you will complete a second structured review cycle on your teammates' team-project Pull Requests (PRs). The focus is release readiness: verify that unfinished sprint items were addressed, confirm authentication behavior is safe and usable, and ensure metadata implementation is consistent and complete. By the end of this activity, you should be able to evaluate whether a Pull Request is ready to merge into main for final project delivery.

Activity Instructions

Confirm review assignments

As a team, confirm reviewer-to-Pull Request assignments in your Teams channel so every open Pull Request receives meaningful feedback this week.

• Each team member should review at least one teammate's PR.
• Prioritize PRs with unfinished sprint carryover, authentication changes, or cross-cutting architecture updates.
• Post final assignments in Teams with reviewer name and Pull Request URL.

Locate your teammate's Pull Request

Open your team project repository and navigate to the Pull Request assigned to you.

• Confirm the Pull Request references the correct user story or issue(s).
• Check whether the description includes known gaps and current testing notes.

Review the Pull Request

Use Files changed in GitHub and perform a complete review of behavior, code quality, and readiness to merge.

1. Start with intent: read the Pull Request description, linked issue(s), and acceptance criteria before reviewing the diff.

   The diff is a comparison of file changes between two versions. In GitHub, the diff helps you inspect exactly what changed and why.

2. Verify behavior: pull the branch and test critical paths before approving.

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

3. Comment in context: leave line-level comments in GitHub with clear impact and suggested fixes where possible.

   Review expectations

   • Review the implementation, not the person.
   • Prioritize correctness, security, accessibility, performance, and maintainability.
   • Reference acceptance criteria and sprint goals in your feedback.
   • Call out blockers explicitly when merge should not proceed.

   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 review decision.

   1. User story and sprint alignment
      • Does the Pull Request clearly map to assigned user story or to an issue?
      • Were carryover sprint items completed or clearly re-scoped?
      • Is unrelated work kept out of the PR?
   2. Functionality and correctness
      • Does the feature work as described?
      • Are validation, edge cases, and error states handled?
      • Are there regressions in existing behavior?
   3. Authentication quality
      • Are protected routes and auth checks implemented correctly?
      • Do login/logout/session behaviors work consistently?
      • Are user-specific actions blocked when unauthorized?
   4. Metadata quality
      • Are page titles and descriptions present and meaningful?
      • Is metadata consistent across layouts and key routes?
      • Are shared metadata patterns implemented cleanly?
   5. Next.js/TypeScript practices
      • Are server and client boundaries used appropriately?
      • Are types explicit and safe (minimal any)?
      • Are async operations and failure paths handled clearly?
   6. Accessibility and UX
      • Are labels, semantic HTML, and keyboard access considered?
      • Are loading, empty, and error states understandable?
      • Are visible UI changes coherent and consistent?
   7. Pull Request hygiene and merge readiness
      • Is the Pull Request description complete and easy to follow?
      • Are screenshots or notes provided for UI changes?
      • Are remaining blockers explicitly listed before merge?
4. Submit one clear decision: Finalize your review with Approve, Request changes, or Comment and include a concise summary.

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 non-blocking feedback.
3. Post a short summary comment that includes:
   • What was reviewed (issue/user story)
   • 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 and a short summary of your key feedback.

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