CSE 341 | Learning Activity

W03 Learning Activity: Code Reviews

Overview

Purpose: Learn about effective code reviews.
Task: Read the following information and complete the activity instructions below.

Beginning this week, you will work in a shared team repository. That means your code can affect your teammates, and your teammates' code can affect you. You will submit Pull Requests (PRs) so your teammates can review the code, before it is merged. These code reviews will help your team avoid problems and improve the quality of your code.

A code review is not just a formality. It is a structured check of whether a change is understandable, correct, tested, and safe to merge. In professional software teams, code reviews are one of the main ways engineers learn a codebase and protect shared systems from introducing bugs.

Code Reviews in Industry

Code reviews are absolutely used in industry today. Most companies require at least one code review before code can be merged into the main branch. AI is often used as a first pass to find possible issues, but most companies still require a human review before code is approved and merged.

Why Code Reviews Matter

They catch bugs and missing tests before code reaches main.
They help the whole team understand changes in the codebase.
They improve consistency across routes, controllers, models, and documentation.
They create a record of design decisions and tradeoffs, including the benefits and costs of each choice.

In this course, code reviews also help you practice communicating about code. You will need to explain risks, ask questions, and give useful feedback without rewriting your teammate's work for them.

What a Pull Request Should Tell You

Before reviewing code, read the pull request description and any GitHub issues it references. A useful pull request should explain:

Which GitHub issue it resolves.
What behavior changed.
Which files or areas of the app changed.
How the author tested the change.
Anything the reviewer should pay special attention to.

If a pull request does not include this information, one of your review comments can ask the author to add it. Reviewing without understanding the purpose of the change is like grading an answer without reading the question.

What to Review

A good review focuses on behavior, maintainability, and risk. Start with the purpose of the change, then inspect the code that implements it.

Review flow

Read the GitHub issue and pull request description.
Check the changed files to understand the scope.
Review the main route, controller, model, middleware, or frontend entry point.
Compare the implementation with the test notes, Swagger docs, and expected behavior.
Leave comments where you see a bug, risk, question, or useful confirmation.

Review checklist

Issue match: The change solves the issue without adding unrelated work.
Behavior: Success, failure, and edge cases behave as expected.
Responses: Status codes, JSON response bodies, and error messages make sense.
Data: Mongoose schemas, validation rules, queries, and relationships are appropriate for the feature.
Security: Secrets are not committed, and protected behavior has the needed authentication or authorization checks.
Documentation: Swagger docs or other notes match the implemented API behavior.
Testing: The PR explains what was tested, and the tests match the risk of the change.
Code quality: The code is understandable and follows existing project patterns.

How to Leave a Helpful Review

Be specific. Reference files, lines, routes, status codes, or test cases.
Ask questions when you are unsure.
Explain the risk, not just the preference.
Approve when the change is ready.
Request changes when the PR has a bug, missing requirement, or meaningful risk.

Weak comments versus helpful comments

Weak comment	Helpful comment
"This is wrong."	"This route returns 500 when the ticket id is not found. Should it return 404 instead, since the request is valid but the ticket does not exist?"
"Fix this."	"Could you add `runValidators: true` to this update so the schema validation still applies during PUT requests?"
"Looks good."	"I tested this in Swagger with a valid token and confirmed the route only returns tickets for the authenticated user. The response matches the docs."

A helpful comment tells the author what you noticed, why it matters, and what kind of change or answer would resolve the concern.

Review the code, support the person

Good reviews are direct about the code and respectful toward the author. Your goal is to help the team ship better work, not to win an argument.

Review Outcomes

GitHub gives you several ways to finish a review. Choose the outcome that matches what you found.

Comment: use this when you have feedback or questions but are not approving or blocking the PR yet.
Approve: use this when the PR is ready to merge.
Request changes: use this when the PR has a bug, missing requirement, unsafe behavior, or another issue that should be fixed before merge.

Requesting changes is not rude when it is done clearly and respectfully. It is part of protecting the team codebase.

Required Review Content

For the code review assignments in this course, each code review you submit must include at least two meaningful comments. At least one comment should address behavior, testing, security, data modeling, or documentation.

A review that only says "looks good" is not enough. If the PR is truly simple and correct, explain what you checked before approving it.

A meaningful review comment might do one of the following:

Confirm a specific test you ran or checked.
Identify a bug, missing requirement, unclear edge case, or mismatch with the issue.
Ask a question about a design decision or tradeoff.
Point out where documentation, tests, or implementation do not agree.
Explain why a piece of code looks correct and safe to merge.

Helpful review examples

I tested GET /routes in Swagger and it returns the new schedule field. The docs match the response shape.

Question: should this route return 401 when no token is provided? Right now it returns 500 from the middleware.

This schema reference looks right to me because tickets can be managed separately from routes. I confirmed the ref name matches the Route model.

How to Review Without Running Everything

Sometimes you may not have time or setup access to fully run a teammate's branch. You can still provide useful review, but be honest about what you checked.

If you ran the code, say what you tested.
If you only reviewed the code, say that you reviewed the code but did not run it.
If you need the author to add test notes, ask for them.

I reviewed the code changes but did not run this branch locally. The schema and route wiring look consistent with the existing station routes. Could you add the Swagger test results to the PR description before merge?

Every PR needs a review

Coordinate with your team so every pull request receives at least one review. If you have already completed two reviews but a teammate still has an unreviewed PR, help the team by reviewing it.

After a PR Is Approved

After a pull request has been reviewed and approved, make sure it gets merged. Generally, the author should merge their own PR after it has been approved, but you can discuss this with your team.

Do not assume an approved PR is finished until it has been merged.
If you approve a PR, remind the author or team in Microsoft Teams that it is ready to merge.
After a PR is merged, teammates should pull the latest main branch before starting or continuing work.

Reviewing a PR that has already been merged

When possible, review PRs before they are merged. For this code review assignment, you may review a PR that has already been merged if there are no new PRs to review.

When reviewing an already-merged PR, make it clear that your review happened after merge. Focus on what you checked, what you learned, and whether you noticed any follow-up work.

Activity Instructions

Beginning in Week 03, you will review at least two PRs each week. You will submit links to your reviews at the start of Week 04.