32. Code Review Checklist (Detailed)

Proses Code Review dilakukan untuk menjaga kualitas basis kode (codebase), meminimalkan celah keamanan, berbagi pengetahuan, serta menjaga konsistensi standar kode di dalam tim.

Dokumen ini berisi panduan praktis dan checklist bagi penulis kode (Author) sebelum membuat Pull Request (PR) dan peninjau (Reviewer) sebelum memberikan persetujuan (Approval).

A. Alur Proses Pull Request & Code Review

Diagram di bawah ini menggambarkan alur kerja yang direkomendasikan sejak fitur selesai dikembangkan secara lokal hingga berhasil digabungkan (merged) ke cabang utama:

graph TD
    A[Fitur Selesai Dikembangkan] --> B[Validasi Lokal: Lint, Format, Build]
    B --> C{Apakah Validasi Lokal Lolos?}
    C -- Tidak --> D[Perbaiki Kode Secara Lokal]
    D --> B
    C -- Ya --> E[Push Branch & Buat Pull Request]
    E --> F[CI/CD Pipeline Checks]
    F --> G{Apakah CI/CD Lolos?}
    G -- Tidak --> H[Perbaiki & Push Ulang]
    H --> F
    G -- Ya --> I[Peer Review oleh Tim Senior/Rekan Kerja]
    I --> J{Membutuhkan Perubahan?}
    J -- Ya --> K[Author Melakukan Perubahan]
    K --> E
    J -- Tidak --> L[Reviewer Memberikan Approve]
    L --> M[Merge ke Main Branch]

B. Checklist Utama Review

Berikut adalah checklist utama yang perlu diperhatikan oleh Reviewer dan Author:

1. Fungsionalitas & Logika Bisnis (Functionality & Logic)

• Acceptance Criteria (AC): Pastikan semua fungsionalitas yang tertuang dalam tiket tugas (Jira/Trello/Gitlab Issue) telah terpenuhi tanpa ada yang terlewat.
• Penanganan Kondisi Edge Cases: Evaluasi bagaimana aplikasi merespons kondisi ekstrem seperti input kosong, string sangat panjang, nilai negatif, data bernilai null atau undefined.
• Penanganan Error & Loading State: Pastikan setiap proses asinkronus (API Call) memiliki status pemuatan (loading state) dan penanganan kesalahan (error handling) yang memadai agar tidak membingungkan pengguna jika jaringan terputus.

// ❌ HINDARI (Tidak menangani status loading dan error secara eksplisit):
const UserList = () => {
  const { data } = useFetchUsers();
  return (
    <ul>
      {data.map((user) => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
};

// ✅ SELALU GUNAKAN:
const UserList = () => {
  const { data, isLoading, error } = useFetchUsers();

  if (isLoading) return <Spinner aria-label="Memuat daftar pengguna" />;
  if (error)
    return (
      <ErrorMessage message="Gagal memuat data pengguna. Silakan coba lagi." />
    );
  if (!data || data.length === 0)
    return <EmptyState message="Tidak ada pengguna yang terdaftar." />;

  return (
    <ul className="divide-y divide-zinc-200">
      {data.map((user) => (
        <li key={user.id} className="py-2">
          {user.name}
        </li>
      ))}
    </ul>
  );
};

2. Clean Code & Struktur Kode (Clean Code Principles)

• Penerapan DRY, KISS, & YAGNI:
  • DRY (Don't Repeat Yourself): Hindari penyalinan logika yang sama persis di beberapa file.
  • KISS (Keep It Simple, Stupid): Tulis kode yang lugas. Hindari trik-trik sintaksis rumit yang sulit dibaca rekan kerja lain.
  • YAGNI (You Ain't Gonna Need It): Jangan menulis fungsi "antisipasi masa depan" yang tidak ada relevansinya dengan tugas saat ini.
• Early Returns (Menghindari Nested Conditions): Struktur percabangan if-else yang mendalam mengurangi keterbacaan kode secara drastis. Lakukan pemeriksaan awal dan segera kembalikan nilai (return early).
• Pembersihan Dead Code: Pastikan tidak ada variabel, fungsi, atau import yang tidak terpakai. Hapus semua console.log, komentar debug, dan blok kode yang di-komentar sebelum PR diajukan.

// ❌ HINDARI (Nesting if-else mendalam & memuat console.log):
function processPayment(user, cart) {
  console.log("Memproses pembayaran untuk user:", user);
  if (user) {
    if (user.isVerified) {
      if (cart.items.length > 0) {
        return executePayment(user, cart);
      } else {
        return "Keranjang kosong";
      }
    } else {
      return "User belum terverifikasi";
    }
  } else {
    return "User tidak valid";
  }
}

// ✅ SELALU GUNAKAN (Early return, bersih dari console.log):
function processPayment(user, cart) {
  if (!user) return "User tidak valid";
  if (!user.isVerified) return "User belum terverifikasi";
  if (!cart.items || cart.items.length === 0) return "Keranjang kosong";

  return executePayment(user, cart);
}

3. TypeScript & Keamanan Tipe (Type Safety)

• Hindari Penggunaan any: Penggunaan tipe any meniadakan fungsi utama dari TypeScript. Jika struktur data tidak diketahui secara pasti, gunakan tipe unknown dan lakukan type narrowing (seperti typeof atau custom type guard).
• Definisikan Tipe Data dengan Jelas: Selalu buat interface atau type untuk props, respon API, dan state yang kompleks.
• Optional Chaining & Nullish Coalescing: Gunakan ?. dan ?? untuk menghindari error run-time yang disebabkan oleh pembacaan properti dari objek bernilai null atau undefined.

// ❌ HINDARI (Menyerah pada type safety menggunakan any):
const handleUserData = (response: any) => {
  const name = response.data.profile.name; // Berisiko memicu crash jika profile bernilai undefined
  return name;
};

// ✅ SELALU GUNAKAN:
interface UserResponse {
  data: {
    profile?: {
      name: string;
    };
  };
}

const handleUserData = (response: UserResponse): string => {
  return response.data.profile?.name ?? "Guest User";
};

4. Arsitektur Komponen & Reusability

• Pemisahan Logika (Separation of Concerns): Komponen presentasional (UI atom seperti button, input) tidak boleh memiliki logika bisnis. Logika bisnis harus ditempatkan di level container, page, atau ditarik keluar ke dalam custom hooks.
• Single Responsibility: Satu komponen atau fungsi sebaiknya hanya memiliki satu tanggung jawab atau tugas utama.
• Batasi Prop Drilling: Jika data harus diturunkan melintasi lebih dari 3 level komponen, gunakan React Context atau sistem manajemen state global (seperti Zustand atau Redux) yang disepakati tim.

5. Performa & Manajemen Sumber Daya (Performance Optimization)

• Gunakan useMemo dan useCallback secara Tepat: Hindari pembungkusan semua fungsi dan nilai dengan useCallback dan useMemo tanpa analisis rasional. Gunakan hanya untuk operasi komputasi berat atau untuk menjaga referensi objek agar tidak memicu re-render tidak perlu pada komponen anak yang dioptimasi dengan memo.
• Pembersihan Efek (Cleanup in useEffect): Pastikan setiap timer (setTimeout, setInterval), event listener, atau subscription dibersihkan saat komponen di-unmount untuk mencegah kebocoran memori (memory leaks).
• Lazy Loading Komponen & Aset: Gunakan dynamic imports (next/dynamic atau lazy) untuk bagian halaman atau modul dialog besar yang tidak langsung terlihat saat memuat halaman pertama kali.

// ❌ HINDARI (Kebocoran memori karena event listener tidak dibersihkan):
useEffect(() => {
  window.addEventListener("resize", () => {
    console.log(window.innerWidth);
  });
}, []);

// ✅ SELALU GUNAKAN (Ada pembersihan event listener):
useEffect(() => {
  const handleResize = () => {
    // Logika pengolahan ukuran layar
  };

  window.addEventListener("resize", handleResize);

  return () => {
    window.removeEventListener("resize", handleResize);
  };
}, []);

6. Keamanan (Security Guidelines)

• XSS (Cross-Site Scripting) Prevention: Penggunaan dangerouslySetInnerHTML harus sangat dihindari. Jika memang terpaksa merender HTML dinamis dari backend, string HTML tersebut wajib dibersihkan (sanitized) menggunakan pustaka seperti dompurify sebelum disajikan.
• Penyimpanan Data Sensitif: Jangan pernah menyimpan informasi sensitif (seperti API Keys, password, rahasia klien) di dalam source code front-end maupun di dalam penyimpanan lokal client-side (localStorage/sessionStorage) yang rentan terhadap serangan XSS. Gunakan variabel lingkungan (Environment Variables) yang aman dan cookie bersandi HttpOnly.

7. Aksesibilitas (A11y Checks)

• Semantik HTML: Pastikan struktur HTML logis. Gunakan elemen tombol (<button>) untuk aksi di halaman dan tag anchor (<a>) hanya untuk perpindahan alamat/routing.
• Keyboard Navigation & Focus States: Aplikasi harus sepenuhnya dapat dinavigasi menggunakan tombol Tab. Jangan pernah menghilangkan outline fokus (outline: none) tanpa menyertakan gaya visual pengganti yang memadai.
• Atribut ARIA: Terapkan atribut aria-label, aria-expanded, atau aria-live untuk memperjelas interaksi dinamis bagi pengguna pembaca layar (screen reader).
• Alt Text: Semua gambar non-dekoratif wajib dilengkapi atribut alt yang deskriptif.

8. Git Workflow, Commits, & Pull Request Etiquette

• Conventional Commits: Format commit harus rapi dan bermakna (misalnya, feat: add user login form atau fix: resolve crash on null api response).
• Deskripsi Pull Request yang Jelas: Jelaskan secara singkat "apa" perubahan yang diusulkan, "mengapa" perubahan tersebut diperlukan, dan "bagaimana" cara mengujinya.
• Gunakan Screenshot/GIF: Untuk perubahan yang melibatkan elemen visual atau UI, lampirkan bukti visual berupa tangkapan layar atau rekaman demo perubahan di deskripsi PR.

C. Template Evaluasi Code Review (Untuk Reviewer)

Berikut adalah template ringkas berbentuk tabel markdown yang dapat disalin dan ditempel oleh Reviewer di kolom komentar Pull Request sebagai bukti bahwa pengecekan menyeluruh telah dilakukan:

### 📝 Code Review Summary Checklist

| Kategori Checklist           |         Status          | Catatan Reviewer |
| :--------------------------- | :---------------------: | :--------------- |
| **Fungsionalitas & AC**      | ⬜ Pass / ⬜ Needs Work |                  |
| **Clean Code & DRY/KISS**    | ⬜ Pass / ⬜ Needs Work |                  |
| **TypeScript & Type Safety** | ⬜ Pass / ⬜ Needs Work |                  |
| **Arsitektur & Reusability** | ⬜ Pass / ⬜ Needs Work |                  |
| **Optimasi Performa**        | ⬜ Pass / ⬜ Needs Work |                  |
| **Keamanan (Security)**      | ⬜ Pass / ⬜ Needs Work |                  |
| **Aksesibilitas (A11y)**     | ⬜ Pass / ⬜ Needs Work |                  |
| **Git & PR Quality**         | ⬜ Pass / ⬜ Needs Work |                  |

**Rekomendasi Akhir:**

- [ ] Approved to Merge
- [ ] Request Changes (Silakan perbaiki catatan di atas terlebih dahulu)

Dengan mematuhi checklist ini, kita dapat menjaga kualitas basis kode dalam jangka panjang dan meminimalkan eror di produksi.