← VCE Software Development U4O2

Peer code review process

Another developer checks a change before it is merged, using a checklist that includes security checks, and approves it. The decision is recorded on the pull request.

Part of: VCE Software Development - U4O2 - Cyber Security: secure software development practices — Module 62, WA Computer Science ATAR Year 11 — Cyber Security — Module 179

Understanding Peer code review process in VCE Software Development U4O2

What it does: A security checklist is used in the review, and a ticked item shows the reviewer checked that security requirement. Recording the reviewer and the decision on the pull request keeps a record of who reviewed the change and what was decided. A peer review needs a second pair of eyes. Authors often miss their own mistakes, including security flaws. Review is a gate. Problems are caught before the code is merged, when they are cheapest to fix. A security checklist targets risks such as missing input validation, hard-coded secrets and weak access control, not personal style. A change with a security flaw must not be approved. Request changes, then re-review once the fix is made.

Common mistakes: A peer code review needs another developer. The author cannot review their own change. It should be reviewer = other_dev(author). The reviewer should only approve when every checklist item passes, including the security checks. It should be checklist.all_passed(), not any_passed().

Class: _____________________  ·  Name: _____________________  ·  Date: _________

Free printable worksheet with full answer key — or add this module to a class and your students practise it interactively.

🖨 Print worksheet + answer key Add Peer code review process to a class →

This module's key terms are also in a printable crossword (Modules 49–72) and word search (Modules 49–130).

Take this worksheet further — free with Cloodit

Each concept is reinforced from every angle — learned, then applied, then tested.

Learning
Duo
Who should review a code change in a peer code review?
Another developer, not the author of the changeThe developer who wrote the change, checking their own work
Matches
git merge feature/login (no review done)
↓
The change was merged without a peer reviewing it or approving it, so no security checks were applied.
Applying
Meanings
Term
peer code review
Meaning
Another developer checks a change before it is merged, using a checklist that includes security checks, and approves it. The decision is recorded on the pull request.
Practice
pull_request ← "Add login form"
Testing
Gaps
git origin feature-login
Check Answer
Spots
1reviewer = author
2checklist = load_checklist()

Cloodit turns curriculum-aligned coding content into journeys students work through one biome at a time.

The 'Ostrich' badge — Full Sprint, one of Cloodit's 106 collectible badges
Students earn collectable badges

Over 100 of them, across seven natural biomes.

Study Buddy
Students build a real study resource

Turns their work into revision material ready for Flash Cards and Exam study.

Diamond Dash — one of Cloodit's live, competitive Sprint games
Students lock in with Sprints

Live, competitive practice for the start of the lesson or a teacher-led lesson finisher.

A Cloodit certificate of achievement, ready to personalise and print
Custom printable certificates

Honour your top performers, or encourage a student who's trying hard — ready to print in seconds.

Add to class →

Quick Questions

1. Who should review a code change in a peer code review?
A. The developer who wrote the change, checking their own work
B. Another developer, not the author of the change ✓
A peer review needs a second pair of eyes. Authors often miss their own mistakes, including security flaws.
2. When does a peer code review happen in a pull request workflow?
A. After the change has been merged and released to users
B. Before the change is merged into the main branch ✓
Review is a gate. Problems are caught before the code is merged, when they are cheapest to fix.
3. Which item belongs on a security checklist used in a peer code review?
A. Is user input validated before it is used in a query? ✓
B. Does the code use the author's favourite variable names?
A security checklist targets risks such as missing input validation, hard-coded secrets and weak access control, not personal style.
4. A reviewer finds a hard-coded API key in the pull request. What should they do?
A. Request changes so the key is removed and stored outside the source code ✓
B. Approve the pull request and mention the key in a chat later
A change with a security flaw must not be approved. Request changes, then re-review once the fix is made.
5. What does approval before merge mean?
A. The reviewer signs off that the change passed the checklist, and only then can it be merged ✓
B. The author merges first and the reviewer signs off whenever they have time
Approval is the control point. Merging without sign-off defeats the purpose of the review.

Match the Pairs

git push origin feature/login → Sends your branch to the shared repository so a pull request can be opened for a peer to review before merging
Status: Approved by reviewer → A peer has finished the review, the checklist is satisfied, and the change is allowed to be merged
A security checklist item the reviewer ticks off during a peer review → [x] Input is validated before use in queries
The review decision is recorded on the pull request so there is an audit trail → Reviewer: Sam | Decision: Changes requested
git merge feature/login (no review done) → The change was merged without a peer reviewing it or approving it, so no security checks were applied.
Reviewer: the author approves own pull request → The author approved their own change, so no independent peer checked it against the security checklist.

Key Term

peer code review
Another developer checks a change before it is merged, using a checklist that includes security checks, and approves it. The decision is recorded on the pull request.

Fill in the Blanks

1. git push origin feature-login
Hint: Type the git command that uploads your branch to the remote so a pull request can be opened.
2. IF reviewer != author THEN startReview
Hint: Type the comparison operator meaning 'is not equal to', so the author cannot review their own change.
3. IF checklistPassed AND approved THEN merge
Hint: Type the logical operator that needs both the checklist and the approval to be true before merging.
4. pullRequest.decision = "approved"
Hint: Type the name of the pull request field that records the outcome of the review.
5. IF checksOk THEN approve ELSE reject
Hint: Type the keyword for the alternative path taken when the security checklist is not passed.

Spot the Error

Question 1
A reviewer = author
B checklist = load_checklist()
C review(pr, checklist)
Line A — A peer code review needs another developer. The author cannot review their own change. It should be reviewer = other_dev(author).
Question 2
A pr = open_pr(branch)
B reviewer.read(pr.changes)
C reviewer.tick(checklist)
D if checklist.any_passed():
E pr.approve()
F merge(pr)
Line D — The reviewer should only approve when every checklist item passes, including the security checks. It should be checklist.all_passed(), not any_passed().
Question 3
A for item in checklist:
B ok = reviewer.check(item)
C if not ok:
D pr.approve()
Line D — When a checklist item fails, the reviewer must request changes. Approving the pull request would let an unsafe change through. It should be pr.request_changes().
Question 4
A pr = get_pull_request(42)
B if not pr.approved:
C merge(pr)
D else:
E notify(pr.author)
Line B — A change is merged only after it has been approved. With 'not', unapproved changes would be merged. It should be if pr.approved:.
Question 5
A decision = 'approved'
B print(decision)
C pr.add_comment(notes)
D merge(pr)
Line B — The review decision must be recorded on the pull request so there is a record of who decided what. Printing it leaves no record. It should be pr.record(decision, reviewer).

Student with a class code? Join your class →