18.6 Refactor sebagai Investasi untuk AI

Bayangkan Anda mewarisi sebuah kode yang sudah berjalan tiga tahun. Fungsinya benar, tidak ada bug yang dilaporkan, dan bisnis berjalan lancar. Tapi setiap kali Anda ingin menambahkan fitur kecil, Anda harus membaca sepuluh file, melacak enam dependency, dan mencari tahu mana logika yang masih dipakai dan mana yang sudah mati. Kode itu bekerja, tapi tidak ramah untuk diubah.

Di sinilah banyak tim ragu. “Kalau tidak rusak, kenapa harus diperbaiki?” Argumen itu masuk akal selama yang mengerjakan perubahan adalah manusia. Manusia bisa membaca kode yang berantakan, pelan-pelan memahami polanya, dan tetap menghasilkan perubahan yang benar. Tapi di era AI, argumen itu mulai goyah.

AI bekerja dengan membaca konteks. Semakin semrawut kode Anda, semakin sedikit konteks relevan yang bisa ditangkap oleh AI dalam satu jendela perhatian. AI bisa membaca seribu baris, tapi jika seribu baris itu berisi campuran logika bisnis, kode legacy yang tidak terpakai, dan workaround yang menumpuk, AI tidak akan bisa membedakan mana yang penting dan mana yang sampah. Hasilnya? AI menghasilkan kode yang terlihat benar secara sintaks, tapi secara semantik meleset.

Refactor di sini bukan soal estetika. Bukan soal nama variabel yang indah atau indentasi yang rapi. Refactor adalah soal membuat batas-batas logika menjadi eksplisit sehingga AI bisa melihat modul mana yang bertanggung jawab atas apa. Ketika Anda memisahkan kode validasi dari kode penyimpanan, AI tidak perlu membaca dua hal sekaligus. Ketika Anda memindahkan logika harga ke satu fungsi murni tanpa efek samping, AI bisa mengubahnya tanpa mengganggu state sistem.

Coba lihat dari sisi praktis. Anda punya sebuah fungsi yang panjangnya dua ratus baris, mencampur kalkulasi, akses database, dan logging. Ketika Anda minta AI menambahkan satu kondisi diskon, AI harus membaca dua ratus baris untuk memahami konteks. Kemungkinan besar AI akan salah menempatkan kondisi itu, atau malah mengubah bagian yang tidak seharusnya. Setelah Anda refactor fungsi itu menjadi tiga fungsi kecil—satu untuk kalkulasi, satu untuk akses data, satu untuk logging—AI hanya perlu membaca fungsi kalkulasi yang panjangnya tiga puluh baris. Akurasinya naik, risikonya turun.

Berikut contoh konkret dalam JavaScript: fungsi monolitik yang mencampur kalkulasi, database, dan logging, lalu versi refactored-nya.

// Sebelum refactor: satu fungsi besar (200 baris)
function prosesPesanan(pesanan) {
  // kalkulasi harga
  let total = 0;
  for (const item of pesanan.items) {
    total += item.harga * item.jumlah;
  }
  if (total > 100000) total *= 0.9; // diskon

  // akses database
  const db = getDatabase();
  db.query('INSERT INTO pesanan ...');

  // logging
  console.log('Pesanan diproses:', total);
  return total;
}

// Setelah refactor: fungsi murni terpisah
function hitungTotal(items) {
  let total = items.reduce((sum, item) => sum + item.harga * item.jumlah, 0);
  return total > 100000 ? total * 0.9 : total;
}

function simpanPesanan(pesanan, total) {
  const db = getDatabase();
  db.query('INSERT INTO pesanan ...', [pesanan.id, total]);
}

function logPesanan(pesanan, total) {
  console.log('Pesanan diproses:', total);
}

// AI cukup fokus pada hitungTotal (30 baris) tanpa khawatir efek samping

Refactor juga membuat verifikasi lebih mudah. Ketika kode sudah terstruktur, Anda bisa menuliskan kontrak di setiap batas modul: fungsi ini menerima angka, mengembalikan angka, dan tidak menyentuh database. AI yang bekerja di dalam batas itu tidak bisa merusak bagian lain. Anda tidak perlu mereview seluruh sistem setiap kali AI membuat perubahan. Anda cukup review satu modul.

Berikut adalah ilustrasi alur transformasi kode dari satu fungsi besar menjadi modul-modul terpisah dengan batas eksplisit.

flowchart TD A["Fungsi Monolitik (200 baris)"] --> B["Pemisahan Logika"] B --> C["Modul Validasi"] B --> D["Modul Logika Harga"] B --> E["Modul Penyimpanan"] B --> F["Modul Logging"] C --> G["Input -> Output"] D --> H["Fungsi Murni"] E --> I["Akses Database"] F --> J["Efek Samping"] G --> K["AI fokus pada 30 baris"] H --> K I --> L["Verifikasi per modul"] J --> L K --> M["Akurasi naik, risiko turun"] L --> M

Ini adalah investasi. Sama seperti Anda merapikan gudang sebelum mempekerjakan asisten baru. Asisten itu bisa bekerja lebih cepat, lebih akurat, dan lebih aman jika barang-barang sudah diberi label dan diletakkan di rak yang benar. Kode yang sudah direfactor adalah rak yang rapi. AI tinggal mengambil dan meletakkan tanpa membongkar seluruh gudang.

Dengan fondasi yang kuat, kita bisa melihat bahwa refactor bukanlah tanda kegagalan, melainkan investasi agar AI lebih efektif. Dan setelah kode rapi, pertanyaan selanjutnya bukan lagi “bagaimana membuat AI mengerti kode saya”, melainkan “bagaimana saya bisa memanfaatkan AI untuk mengeksplorasi kemungkinan-kemungkinan baru tanpa kehilangan kendali”.