Week 8

Mid Project Review & Code Review

Mobile Programming

Flutter • Git Flow • Pull Request • Code Review • Static Analysis

From code that runs to code that passes team review

Learning Outcomes

After this session, students will be able to:

  1. Explain Git Flow and branching strategy.
  2. Write quality commits and pull requests.
  3. Perform constructive code reviews.
  4. Run static analysis and linters.
  5. Assess mid-semester project readiness.
  6. Verify AI-generated review suggestions.

Why Review?

The Week 7 project is tidy, but:

Commit "fix bug" with no context, untraceable
800-line PR with no description, reviewers lost
Mixed styles per file, reviews wasted on spacing

Team projects need discipline:

small branch -> small PR -> fast review
clear commits -> readable history
clean analyze -> reviews focus on logic

Goal: code that is not only working, but collaboration-ready.

Mini Poll

Which commit is easiest to review?

A. fix bug
B. feat(notes): validate empty title
C. update
D. final fix for real

Discussion

What is the difference between "working code" and "review-ready code"?

Part 1

Git Flow & Collaboration

Branching Model

Part 1 - Git Flow: one branch, one purpose.

main      -> always releasable, protected
develop   -> weekly feature integration
feature/* -> daily work, short-lived
fix/*     -> quick fixes + tests

Ground rule:

Branch from develop, PR back to develop.
main only via release. No direct commits.

Quality Commits

One commit = one logical, reviewable change.

good: feat(notes): validate empty title + test
good: fix(auth): refresh token before one retry
bad: fix bug / update / final fix for real

Format: type(scope): short description

feat, fix, refactor, test, docs, chore.

Anatomy of a Pull Request

Small PRs get reviewed fast. Huge PRs scare reviewers.

Title: feat(notes): validation + test (one feature max)
Body: problem -> solution -> how to test -> screenshot
Size: < 300 lines, < 3 days of work
Status: analyze + tests green before requesting review

A PR without test steps is not ready.

Issue Tracking

Every PR starts from a clear issue.

issue #42 -> branch fix/42-login-crash
  -> small commits -> PR "Closes #42"
  -> review -> merge -> issue closed

Checklist for a good issue:

  • Reproduction steps + expected result
  • Clear labels and priority

Part 2

Code Review & Static Analysis

What Gets Reviewed?

Order focus from important to trivial:

  1. Correctness - logic, edge cases, error handling.
  2. Architecture - dependency direction, layers, contracts.
  3. Readability - names, small functions, needed comments.
  4. Tests - tests for new behavior?
  5. Style - leave to the formatter, not debate.

Never spend reviews on spacing. Automate it.

15-Minute Review Checklist

Find at least the following in a peer review:

  • 2 correctness issues (null, state, error paths)
  • 1 architecture violation (cross-layer import)
  • 1 test gap (missing success/failure case)
  • 1 readability issue (name / oversized function)
  • 1 concrete suggestion + reason

End with a decision: Approve / Request changes.

Good Review Comments

Tough on code, kind to humans.

weak: "this code is bad, fix it"
good: "This function is 60 lines with 3 jobs.
  Suggestion: extract validation to core/validate.dart.
  Reason: unit-testable without widgets."

Pattern: observation -> impact -> concrete proposal.

Static Analysis & Linters

Let machines catch the mechanical issues.

flutter analyze        # must be clean, zero warnings
dart format --set-exit-if-changed .
flutter test           # green before PR

Enforce in CI so dirty PRs are rejected automatically.

Human reviewers focus on design, not semicolons.

Reading Analyze Output

Understand the intent, do not memorize rules.

warning: unused_import -> remove dead imports
info: prefer_const -> use const for cheaper rebuilds
error: must_be_immutable -> widgets must stay immutable

Fix errors first, then warnings, then info.

Part 3

Mid Project Review & Practice

Mid-Semester Definition of Done

The project may continue to part two when:

  • Feature-first structure + proven dependency rule
  • flutter analyze clean + green tests
  • Small PRs + clear commits + closed issues
  • Complete README + screenshots + run guide
  • Peer review feedback addressed

Not "many features", but "a trusted foundation".

Lab: A Simple PR

Simulate the team flow in 20 minutes:

1. Create issue: "Validate empty title + test"
2. Branch: git checkout -b feat/notes-validation
3. Small commits + push + open PR to develop
4. Fill template: problem, solution, test steps
5. Ask 1 reviewer, fix, merge
6. Make sure the issue auto-closes

One PR per pair, not per class.

Peer Review Simulation

Swap roles, keep a strict timebox:

  • Author (7 min): demo changes + risks + review focus.
  • Reviewer (7 min): use the shortened checklist.
  • Discussion (6 min): agree fixes + owner.

Goal: every PR gets at least 3 meaningful comments.

AI Lab

Use AI as a Co-Reviewer

Example prompt:

Review this PR as a senior Flutter dev.
Focus: correctness, architecture, tests.
Ignore style. Give top 5 findings
+ severity (blocker/suggestion) + code fix.

Never accept AI output raw.

AI Verification Challenge

After the AI reviews:

  1. Read - understand each finding, no copy-paste.
  2. Verify - cross-check with grep + real tests.
  3. Reject/accept - reject wrong advice with reasons.
  4. Test - analyze + tests stay green.
  5. Fix - apply what is valid, log manual work.
  6. Explain - demo without reading AI notes.

Minimum tests

  • 2 AI findings proven correct with tests
  • 1 AI finding rejected with a reason
  • flutter analyze + flutter test

Review Anti-Patterns

Avoid:

1. Blind LGTM without reading the diff

approving 800 lines in 1 minute = no review

2. Nitpicking without priority

spacing debate while logic leaks pass

3. Reviewing without running

never pull + test, only skim the diff

Group Activity

15-Minute Code Review

Swap PRs between pairs, find at least:

  • 2 correctness issues (null, state, error paths)
  • 1 architecture or leaking-DI violation
  • 1 missing test case
  • 1 exemplary comment (observation + proposal)
  • 1 AI decision rejected/accepted + reason

Then answer:

Is this project ready for part two? Why?

Quick Quiz

1. Branch for daily work?

A. Commit straight to main
B. feature/* from develop
C. Commit to a friend's branch
D. No branch at all

2. What does a good PR look like?

A. 800 lines, many features at once
B. Small, one feature, test steps included
C. No description for speed
D. No tests to stay light

Quiz Answers

1 -> B

feature from develop, back via PR

2 -> B

small + test steps -> fast review

3 -> Run flutter analyze first

machines for style, humans for design

Deliverables

Repository

08-week-8-mid-project-review/
├── docs/
│   ├── review-checklist.md
│   └── ai-review-vs-decision.md
├── README.md
└── screenshots/

Minimum README content:

  • mid-semester status + issue/PR map
  • flutter analyze + flutter test results
  • PR screenshots + review comments
  • AI prompt + proposal-vs-decision table

Week 8 Rubric

Component Weight
Git Flow + PR + Commits 25%
Peer Code Review 25%
Static Analysis + Green Tests 15%
Mid Review + Follow-up 15%
Responsible AI Usage 10%
Presentation & Reflection 10%
Total 100%

Checklist Before Submit

Collaboration

  • [ ] Branch from develop, small one-feature PR
  • [ ] Clear commits, issue closed via PR
  • [ ] Reviewed by 1 peer + followed up

Evidence

  • [ ] flutter analyze clean + green tests
  • [ ] PR screenshots + review comments
  • [ ] Mid-semester status in README

AI

  • [ ] Prompt + decision table recorded
  • [ ] Able to explain findings without AI

Exit Ticket

Answer before class ends:

1. What separates a blind LGTM from a responsible approve?

2. When is "request changes" required, when is a suggestion enough?

3. One AI finding you rejected, and why?

4. One thing you fixed after peer review?

Key Takeaways

Collaboration

Small branches, small PRs, fast reviews.

Review

Tough on code, kind to humans.

Automation

Machines for style, humans for design.

AI

AI proposes the review.
Developers decide.

Next Week

Week 9: AI-Assisted Development / Vibe Coding

Structured project (passed review)
   |
   v
Prompt + context + verification
   |
   v
AI generates, developers test + refactor

Goal

Use AI fast without losing quality control.

Build -> Verify -> Explain

The Mobile Learning Principle

         AI
           |
           v
        Generate
           |
           v
        Developer
           |
           v
          Verify
           |
           v
          Test
           |
           v
        Refactor
           |
           v
         Explain

Do not just be able to write code.

Be a developer who welcomes review and can review others.