Week 8

Mid Project Review & Code Review

Pemrograman Mobile

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

Dari kode yang jalan → kode yang lolos review tim

Learning Outcomes

Setelah mengikuti pertemuan ini, mahasiswa mampu:

  1. Menjelaskan Git Flow dan strategi branching.
  2. Menulis commit dan Pull Request yang berkualitas.
  3. Melakukan code review yang konstruktif.
  4. Menjalankan static analysis dan linter.
  5. Menilai kesiapan project tengah semester.
  6. Memverifikasi saran review dari AI.

Mengapa Review?

Project Week 7 rapi, tapi:

Commit "fix bug" tanpa penjelasan, tak bisa dilacak
PR 800 baris tanpa deskripsi, reviewer bingung
Style beda tiap file, review habis untuk spasi

Project tim butuh disiplin:

branch kecil -> PR kecil -> review cepat
commit jelas -> riwayat bisa dibaca
analyze bersih -> review fokus ke logika

Tujuan: kode yang tidak hanya jalan, tapi layak kolaborasi.

Mini Poll

Commit mana yang paling mudah direview?

A. fix bug
B. feat(notes): tambah validasi judul kosong
C. update
D. final fix beneran

Diskusi

Apa beda "kode jalan" dengan "kode siap direview"?

Bagian 1

Git Flow & Kolaborasi

Branching Model

Bagian 1 - Git Flow: satu branch, satu tujuan.

main      -> selalu rilis, dilindungi
develop   -> integrasi fitur mingguan
feature/* -> kerja harian, pendek
fix/*     -> perbaikan cepat + test

Aturan main:

Branch dari develop, PR kembali ke develop.
main hanya via release. Jangan commit langsung.

Commit Berkualitas

Satu commit = satu perubahan logis yang bisa direview.

baik: feat(notes): validasi judul kosong + test
baik: fix(auth): refresh token sebelum retry 1x
jelek: fix bug / update / final fix beneran

Format: tipe(scope): deskripsi singkat

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

Anatomi Pull Request

PR kecil direview cepat. PR besar ditakuti reviewer.

Judul: feat(notes): validasi + test (maks 1 fitur)
Isi: masalah -> solusi -> cara uji -> screenshot
Ukuran: < 300 baris, < 3 hari kerja
Status: analyze + test hijau sebelum minta review

PR tanpa cara uji = PR yang belum siap.

Issue Tracking

Setiap PR berawal dari issue yang jelas.

issue #42 -> branch fix/42-login-crash
  -> commit kecil -> PR "Closes #42"
  -> review -> merge -> issue tertutup

Checklist issue yang baik:

  • Langkah reproduksi + ekspektasi hasil
  • Label dan prioritas yang jelas

Bagian 2

Code Review & Static Analysis

Apa yang Direview?

Urutkan fokus dari penting ke sepele:

  1. Kebenaran - logika, edge case, error handling.
  2. Arsitektur - arah dependensi, layer, kontrak.
  3. Keterbacaan - nama, fungsi kecil, komentar perlu.
  4. Test - ada test untuk perilaku baru?
  5. Style - serahkan ke formatter, bukan debat.

Jangan habiskan review untuk spasi. Otomatiskan.

Checklist Review 15 Menit

Temukan minimal temuan berikut saat review sejawat:

  • 2 masalah kebenaran (null, state, error path)
  • 1 pelanggaran arsitektur (import lintas layer)
  • 1 masalah test (kasus sukses/gagal kurang)
  • 1 masalah keterbacaan (nama/fungsi besar)
  • 1 saran perbaikan yang konkret + alasan

Akhiri dengan keputusan: Approve / Request changes.

Komentar Review yang Baik

Keras pada kode, baik pada manusia.

kurang: "kode ini jelek, perbaiki"
baik: "Fungsi ini 60 baris + 3 tanggung jawab.
  Usul: pecah validasi ke core/validate.dart.
  Alasan: bisa diunit-test tanpa widget."

Pola: observasi -> dampak -> usulan konkret.

Static Analysis & Linter

Biarkan mesin menangkap yang mekanis.

flutter analyze        # wajib bersih, nol warning
dart format --set-exit-if-changed .
flutter test           # hijau sebelum PR

Aktifkan di CI agar PR kotor ditolak otomatis.

Reviewer manusia fokus ke desain, bukan titik koma.

Baca Output Analyze

Jangan hafal aturan, pahami maksudnya.

warning: unused_import -> hapus import mati
info: prefer_const -> pakai const agar rebuild murah
error: must_be_immutable -> widget tak boleh mutable

Perbaiki dari error dulu, lalu warning, lalu info.

Bagian 3

Mid Project Review & Praktik

Definisi Selesai Tengah Semester

Project layak lanjut ke paruh kedua bila:

  • Struktur feature-first + dependency rule terbukti
  • flutter analyze bersih + test hijau
  • PR kecil + commit jelas + issue tertutup
  • README + screenshot + cara jalan lengkap
  • Review sejawat sudah ditindaklanjuti

Bukan "fitur banyak", tapi "fondasi bisa dipercaya".

Praktikum: PR Sederhana

Simulasi alur tim dalam 20 menit:

1. Buat issue: "Validasi judul kosong + test"
2. Branch: git checkout -b feat/notes-validation
3. Commit kecil + push + buka PR ke develop
4. Isi template: masalah, solusi, cara uji
5. Minta 1 reviewer, perbaiki, merge
6. Pastikan issue tertutup otomatis

Satu PR per pasangan, bukan per kelas.

Simulasi Peer Review

Peran bergantian, timebox ketat:

  • Author (7 mnt): demo perubahan + risiko + minta fokus.
  • Reviewer (7 mnt): pakai checklist 15 menit versi ringkas.
  • Diskusi (6 mnt): sepakati perbaikan + siapa mengerjakan.

Target: tiap PR mendapat minimal 3 komentar bermakna.

AI Lab

Gunakan AI sebagai Co-Reviewer

Contoh prompt:

Review PR ini sebagai senior Flutter dev.
Fokus: kebenaran, arsitektur, test.
Abaikan style. Beri 5 temuan teratas
+ level (blocker/saran) + usulan kode.

Jangan terima mentah output AI.

AI Verification Challenge

Setelah AI memberi review:

  1. Baca - pahami tiap temuan, jangan copy-paste.
  2. Verifikasi - cek silang dengan grep + test nyata.
  3. Tolak/terima - tolak saran salah + alasan tertulis.
  4. Uji - analyze + test tetap hijau.
  5. Perbaiki - terapkan yang valid, catat manual.
  6. Jelaskan - demo tanpa membaca catatan AI.

Uji minimal

  • 2 temuan AI terbukti benar dengan test
  • 1 temuan AI ditolak dengan alasan
  • flutter analyze + flutter test

Anti-Pattern Review

Hindari:

1. LGTM buta tanpa baca diff

approve 800 baris dalam 1 menit = tak review

2. Nitpick tanpa prioritas

debat spasi, logika bocor lolos

3. Review tanpa dijalankan

tak pernah pull + test, hanya baca sekilas

Aktivitas Kelompok

Code Review 15 Menit

Tukar PR antar pasangan, cari minimal:

  • 2 masalah kebenaran (null, state, error path)
  • 1 pelanggaran arsitektur atau DI bocor
  • 1 masalah test yang kurang
  • 1 komentar teladan (observasi + usulan)
  • 1 keputusan AI yang ditolak/diterima + alasan

Kemudian jawab:

Apakah project ini layak lanjut ke paruh kedua? Mengapa?

Quiz Cepat

1. Branch untuk kerja harian?

A. Commit langsung ke main
B. feature/* dari develop
C. Commit ke branch teman
D. Tanpa branch

2. PR yang baik berukuran?

A. 800 baris, banyak fitur sekaligus
B. Kecil, satu fitur, ada cara uji
C. Tanpa deskripsi agar cepat
D. Tanpa test agar ringan

Jawaban Quiz

1 -> B

fitur dari develop, kembali via PR

2 -> B

kecil + cara uji -> review cepat

3 -> Cek flutter analyze dulu

mesin untuk style, manusia untuk desain

Deliverables

Repository

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

README minimal berisi:

  • status paruh semester + peta issue/PR
  • hasil flutter analyze + flutter test
  • screenshot PR + komentar review
  • prompt AI + tabel usulan-vs-keputusan

Rubrik Week 8

Komponen Bobot
Git Flow + PR + Commit 25%
Code Review Sejawat 25%
Static Analysis + Test Hijau 15%
Mid Review + Tindak Lanjut 15%
Responsible AI Usage 10%
Presentasi & Refleksi 10%
Total 100%

Checklist Sebelum Submit

Kolaborasi

  • [ ] Branch dari develop, PR kecil satu fitur
  • [ ] Commit jelas, issue tertutup via PR
  • [ ] Direview 1 teman + ditindaklanjuti

Bukti

  • [ ] flutter analyze bersih + test hijau
  • [ ] Screenshot PR + komentar review
  • [ ] Status paruh semester di README

AI

  • [ ] Prompt + tabel keputusan dicatat
  • [ ] Mampu jelaskan temuan tanpa AI

Exit Ticket

Jawab sebelum kelas berakhir:

1. Apa beda LGTM buta dengan approve bertanggung jawab?

2. Kapan komentar "request changes" wajib, kapan cukup saran?

3. Satu temuan AI yang Anda tolak dan alasannya?

4. Satu hal yang Anda perbaiki setelah review sejawat?

Key Takeaways

Kolaborasi

Branch kecil, PR kecil, review cepat.

Review

Keras pada kode, baik pada manusia.

Otomatisasi

Mesin untuk style, manusia untuk desain.

AI

AI mengusulkan review.
Developer memutuskan.

Next Week

Week 9: AI-Assisted Development / Vibe Coding

Project terstruktur (lolos review)
   |
   v
Prompt + konteks + verifikasi
   |
   v
AI generate, developer uji + refactor

Target

Menggunakan AI cepat tanpa kehilangan kendali mutu.

Build -> Verify -> Explain

Prinsip Pembelajaran Mobile

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

Jangan hanya bisa menulis kode.

Jadilah developer yang berani direview dan bisa mereview.