AI untuk Refactoring

Refactoring: Pekerjaan yang Ditakuti Semua Orang

Refactoring = mengubah struktur kode TANPA mengubah perilakunya. Semua orang tahu kode perlu dirapikan, tapi takut: "kalau aku ubah, yang jalan jadi rusak." AI adalah partner refactoring yang ideal: ia tidak takut kode berantakan 500 baris, ia konsisten menerapkan pola, dan ia bisa memeriksa ulang pekerjaannya. Tapi refactoring dengan AI tanpa disiplin = cara tercepat merusak kode yang tadinya jalan.

Aturan emas refactoring (dengan atau tanpa AI): refactor hanya kode yang punya pengaman (test) atau yang akan kamu uji manual menyeluruh. Jangan refactor kode tanpa cara memverifikasi.

Contoh 1: Refactoring Fungsi Panjang (Praktik)

Kamu punya fungsi 80 baris yang melakukan 5 hal. Pola aman:

Langkah 1, kunci perilaku dulu:

Prompt: "Sebelum refactor, bantu aku mengunci perilaku fungsi ini. Buatkan 5-7 test case (input -> output yang diharapkan) berdasarkan kode ini. Jangan ubah kode dulu. [paste fungsi]"

Jalankan test-test itu, pastikan lolos dengan kode SEKARANG. Ini "gembok" perilakumu.

Langkah 2, refactor bertahap:

Prompt: "Refactor fungsi ini dengan ATURAN: (1) pecah jadi fungsi-fungsi kecil max 20 baris, (2) JANGAN ubah perilaku apa pun, (3) nama fungsi dalam bahasa Inggris yang jelas, (4) kerjakan dan tunjukkan hasilnya per 2 fungsi, jangan sekaligus."

Langkah 3, verifikasi dengan gembok: Jalankan test dari langkah 1 terhadap kode hasil refactor. Semua harus tetap lolos. Kalau ada yang gagal, refactor-nya mengubah perilaku: tolak dan perbaiki.

Pola "kunci > ubah > verifikasi" ini adalah satu-satunya cara refactor aman, dengan AI maupun manual.

Contoh 2: Kapan JANGAN Refactor (Keputusan)

AI selalu antusias merapikan ("boleh aku refactor ini?"). Tapi refactoring tidak selalu tepat. Jangan refactor kalau:

1. Tidak ada test dan tidak ada waktu menguji. Refactor buta = judi. Tunda sampai ada pengaman.
2. Kode akan segera dibuang. "Modul ini mau diganti bulan depan." Merapikan kode yang akan mati = buang waktu.
3. Deadline mepet dan kode jalan. Refactor sehari sebelum rilis = risiko tanpa manfaat. Catat saja sebagai utang teknis ("TODO: refactor fungsi X, alasan: ...").
4. Hanya soal gaya, bukan struktur. Beda selera penamaan bukan alasan refactor berisiko. Pakai formatter otomatis (Prettier) untuk gaya; refactor untuk struktur.

Prompt keputusan: "Kode ini [paste/deskripsi]. Menurutmu apakah layak di-refactor sekarang? Pertimbangkan: tidak ada test, deadline 3 hari, kode ini disentuh tiap minggu. Beri rekomendasi YA/TIDAK dengan alasan."

Catatan teknis: Teknik refactoring klasik yang AI kuasai: Extract Function (pecah fungsi), Rename (nama yang jelas), Replace Magic Numbers (angka misterius jadi konstanta bernama), Simplify Conditionals (kondisi bertingkat jadi early return), dan Remove Duplication (DRY). Minta secara spesifik: "terapkan Extract Function ke fungsi ini" memberi hasil lebih baik daripada "rapikan kode ini". Untuk refactor BESAR (antar file/modul), gunakan strategi strangler fig: jangan ubah kode lama sekaligus; buat versi baru di sampingnya, alihkan pemakaian satu per satu, hapus yang lama kalau sudah tidak dipakai. Minta AI membantu merencanakan: "buatkan rencana migrasi strangler untuk memindahkan modul X ke struktur baru, langkah per langkah yang aman."

Kesalahan Umum

1. Refactor + tambah fitur sekaligus. Dua perubahan perilaku dalam satu langkah = kalau rusak, tidak tahu penyebabnya. Refactor DULU (perilaku sama), commit, BARU tambah fitur.
2. Menerima refactor tanpa menjalankan test. "Kelihatannya bagus" bukan verifikasi. Jalankan test/gembok perilaku setiap kali.
3. Refactor kode yang tidak dipahami. Kalau kamu tidak paham apa yang dilakukan kode, refactor = menata barang di ruangan gelap. Pahami dulu (minta AI menjelaskan), baru rapikan.
4. Terlalu perfeksionis. Refactor bertujuan "cukup baik untuk diubah dengan aman", bukan "sempurna menurut buku". Berhenti saat kode sudah jelas dan teruji.

Rangkuman

Refactoring aman dengan AI = kunci perilaku (test) > ubah bertahap dengan aturan eksplisit > verifikasi dengan kunci yang sama. Minta teknik spesifik (Extract Function, bukan "rapikan"), pisahkan refactor dari tambah fitur, dan tahu kapan TIDAK refactor. AI menghilangkan rasa takut refactoring; disiplin menjaga refactoring tetap aman.