Keuntungan:
- Kemampuan untuk menyiapkan jaring pengaman pengujian yang menangkap perilaku saat ini sebelum melakukan pemfaktoran ulang
- Kemampuan untuk meminta AI melakukan transformasi kecil, satu langkah, dan mempertahankan perilaku serta memvalidasi setiap langkah
- Kemampuan untuk mengidentifikasi dan memprioritaskan utang teknis dalam konteks bisnis
Refactoring adalah memperbaiki struktur internal suatu kode tanpa mengubah perilaku eksternalnya: membuatnya lebih mudah dibaca, sederhana, dan lebih mudah dipelihara. Hutang teknis, di sisi lain, adalah kompromi desain yang dibuat demi solusi cepat dan dibayar kembali "dengan bunga" seiring berjalannya waktu - setiap sudut yang Anda potong hari ini akan kembali menjadi pelambatan atau bug besok. Kecerdasan buatan adalah asisten ampuh yang mempercepat tugas pemfaktoran ulang yang berulang dan mekanis; Namun ada satu aturan utama dalam pemfaktoran ulang, dan AI saja tidak dapat menjaminnya: perilaku tidak boleh berubah.
Dalam unit ini, kita mempelajari cara melakukan pemfaktoran ulang yang aman dengan AI: langkah-langkah kecil dan dapat dibalik, melindungi dengan pengujian, mendeteksi bau kode, dan memprioritaskan utang teknis. Poin pentingnya adalah ini: yang membuktikan bahwa perilaku tersebut dipertahankan adalah hasil tes kelulusan, bukan perkataan AI.
Aturan Emas Refactoring: Perilaku Tetap Konstan
Apa yang membuat refactoring berbahaya adalah tanpa sadar mengubah perilaku sambil mengatakan "Saya membaik". Menghapus kasus tepi saat menyederhanakan suatu kondisi, merusak urutan saat mengubah perulangan, menghilangkan efek samping saat memisahkan suatu fungsi—semuanya menghasilkan kode yang "tampak bersih" namun rusak.
Itu sebabnya pengujian merupakan prasyarat untuk pemfaktoran ulang: sebelum melakukan perubahan, Anda harus memiliki pengujian yang menangkap perilaku yang ada. Tes-tes ini adalah “jaring pengaman”; Jika Anda secara tidak sengaja merusak sesuatu selama pemfaktoran ulang, mereka akan merusak dan memperingatkan Anda. Jika Anda tidak memiliki pengujian, tulis pengujian yang memperbaiki perilaku yang ada terlebih dahulu (seperti yang kita pelajari di unit 5) — di sinilah AI memulainya.
Perhatian: Pemfaktoran ulang yang dibantu AI tanpa testnet adalah salah satu sumber bug yang paling berbahaya. Sangat mudah untuk mengatakan "Saya mempertahankan perilaku tersebut"; Buktinya, ujian yang sama lulus sebelum dan sesudah perubahan.
Langkah demi Langkah: Mengamankan Alur Refactoring
- Siapkan jaring pengaman. Biarkan ada pengujian yang menangkap perilaku kode saat ini yang akan Anda refaktorisasi; Jika belum, tuliskan terlebih dahulu (dan lihat prosesnya).
- Sebutkan baunya. Apa yang Anda tingkatkan dan mengapa? "Fungsi ini melakukan 3 hal", "logika yang sama berulang di 4 tempat", "nama menyesatkan".
- Mintalah langkah kecil satu langkah. Minta AI untuk melakukan satu transformasi (misalnya, cukup “bagi fungsi ini menjadi dua”), bukan menulis ulang seluruh file.
- Jalankan tes. Setelah setiap langkah. Kalau hijau lanjutkan, kalau merah ambil kembali.
- Baca Perbedaan. Konfirmasikan baris demi baris bahwa perubahan tersebut benar-benar menjaga perilaku; Mungkin ada kesalahan logika ketika mengatakan AI adalah "hanya struktur".
- Gabungkan menjadi potongan-potongan kecil. PR pemfaktoran ulang satu kali dalam jumlah besar berisiko dan tidak dapat ditinjau.
Tiga Kasus Mini
Kasus 1 — Fungsi 220 baris terpecah dengan aman. Satu tim memiliki fungsi pemrosesan pesanan 220 baris. 14 tes pertama ditulis (dengan bantuan AI) yang menangkap perilaku saat ini, semuanya lulus. Kemudian fungsi tersebut dibagi menjadi 5 fungsi yang lebih kecil selangkah demi selangkah oleh AI; Pengujian dijalankan setelah setiap langkah. Dua tes dipatahkan dalam satu langkah — AI telah melewatkan pengembalian dalam kasus edge. Pengujian segera menangkapnya dan memperbaikinya. Tanpa jaringan, kesalahan bisa berlanjut hingga ke produksi.
Kasus 2 — Bencana tanpa testnet. Pengembang lain "membersihkan" modul penghitungan tanggal yang tidak diuji dengan AI. Kodenya terlihat lebih baik, tetapi salah menghitung tahun kabisat; Bug tersebut muncul dua minggu kemudian dengan keluhan pelanggan. Kerugiannya jauh melebihi waktu yang dihemat dari pemfaktoran ulang. Pelajaran: refactoring tanpa pengujian adalah sebuah pertaruhan.
Kasus 3 — Prioritas utang teknis. Satu tim memberi AI simpanan sekitar 30 poin “yang dapat ditingkatkan” dan masing-masing tim diberi skor pada sumbu “frekuensi perubahan × risiko × upaya”. Pada tabel yang dihasilkan, modul jelek yang jarang disentuh sebenarnya berprioritas rendah, sedangkan modul dengan kompleksitas sedang yang sering berubah adalah prioritas tinggi. Tim mengarahkan energinya ke tempat yang tepat.
Empat Templat yang Dapat Disalin
Deteksi dan penentuan prioritas bau kode:
Cantumkan kandidat refactoring "bau" dalam kode ini: fungsi panjang, pengulangan (DRYViolation), nama menyesatkan, kondisi bersarang dalam, efek samping tersembunyi, angka ajaib. Untuk masing-masing: lokasi, penyebab masalah, langkah kecil yang disarankan, perkiraan risiko (rendah/sedang/tinggi). JANGAN GANTI kode dulu, rencanakan saja.{{code}}
Transformasi satu langkah yang melestarikan perilaku:
HANYA lakukan ini: {{konversi tunggal, mis. Bagilah fungsi ini menjadi 3 fungsi bernama lebih kecil}}. UBAH perilaku yang terlihat, tanda tangan, dan nilai kembalian. Tulis dalam 1 kalimat mengapa semua yang Anda ubah mempertahankan perilaku tersebut.{{code}}
Jaring pengaman sebelum refactor (pengujian karakterisasi):
Tulis tes yang menangkap perilaku SAAT INI dari fungsi ini (benar atau tidak); tujuannya adalah untuk mengetahui apakah perilaku berubah selama pemfaktoran ulang. Sertakan entri + tepi yang khas. Tulis ekspektasi berdasarkan keluaran fungsi saat ini.{{function}}
Pembuatan catatan utang teknis (backlog):
Tuangkan daftar bau berikut ke dalam tabel prioritas: bahan, area yang terkena dampak, frekuensi perubahan (sepengetahuan saya: {{...}}), risiko, perkiraan upaya, prioritas yang disarankan. Tempatkan dampak tinggi + upaya rendah di atas. {{daftar_bau}}
Perintah lemah / Perintah kuat
Lemah: "Bersihkan kode ini dan jadikan lebih baik."
Kuat: "Pisahkan fungsi 90 baris ini menjadi 3 fungsi yang lebih kecil dengan tanggung jawab tunggal, tanpa mengubah perilaku dan tanda tangan eksternalnya. Pertahankan efek samping (tulisan DB) dalam urutan saat ini. Saya memiliki tes, perilakunya harus tetap sama. Berikan perbedaannya dan jelaskan dalam satu kalimat mengapa setiap pemisahan mempertahankan perilaku. [kode]"
Versi yang kuat; Hal ini memerlukan satu transformasi spesifik, secara eksplisit menerapkan batasan perilaku dan tanda tangan, serta menuntut pembenaran. Permintaan yang tidak jelas seperti “berbuat lebih baik” menyebabkan perubahan yang tidak terkendali dan berisiko.
Jenis pemfaktoran ulang
Keandalan AI
Prasyarat
ganti nama
tinggi
Apakah cakupannya benar?
Pembagian fungsi
sedang-tinggi
Testnet adalah suatu keharusan
Berbagi pengulangan
sedang
Perbedaan perilaku mungkin tersembunyi
Perubahan algoritma/struktur
rendah
Pengujian ekstensif + validasi manusia
Penataan ulang arsitektur
rendah
Dipimpin oleh manusia, didukung AI
Mengelola Utang Teknis, Bukan Menyetel Ulangnya
Utang teknis tidak semuanya buruk; Terkadang meminjam secara sadar (untuk memenuhi kebutuhan) adalah keputusan yang tepat. Tujuannya bukan untuk menghilangkan utang, namun menjadikannya terlihat dan dapat dikelola. AI cepat dalam mendeteksi dan memprioritaskan utang, namun memutuskan “utang mana yang harus dibayar dan mana yang harus ditinggalkan” memerlukan konteks bisnis: seberapa sering modul ini berubah, berapa banyak orang yang terkena dampaknya, apa risikonya? Keputusan ini dibuat oleh tim yang mengetahui basis kode dan produk; AI hanya memperjelas pilihannya.
Tip: Pisahkan PR refactoring Anda dari PR yang melibatkan perubahan perilaku. Mampu mengatakan "PR ini hanyalah refactoring, perilakunya sama" membuatnya lebih mudah untuk diselidiki dan memungkinkan Anda dengan cepat mempersempit penyebabnya jika muncul masalah.
Kesalahan umum
- Memfaktorkan ulang tanpa testnet. Anda tidak mempunyai apa pun untuk membuktikan bahwa perilaku tersebut dipertahankan.
- Artinya "hapus seluruh file". Perubahan besar dan tidak terkendali menyembunyikan kesalahan dan tidak dapat diperiksa.
- Menerima Diff tanpa membacanya. AI mungkin salah logika ketika mengatakan "hanya struktur".
- Membingungkan refactoring dengan perubahan perilaku. Melakukan keduanya dalam PR yang sama membuat pelacakan akar permasalahan menjadi tidak mungkin.
- Mencoba memperbaiki setiap bau. Kode jelek yang jarang berubah sering kali memiliki prioritas rendah; Alokasikan energi ke tempat yang sering berubah.
Singkatnya
Satu-satunya aturan pemfaktoran ulang adalah bahwa perilakunya tetap konstan, dan buktinya adalah pengujian. AI sangat ampuh dalam mendeteksi bau kode, transformasi satu langkah, dan memprioritaskan utang teknis; tetapi Anda harus menyiapkan jaring pengaman, menjalankan pengujian, dan membaca perbedaannya setelah setiap langkah. Ambil langkah-langkah kecil dan dapat dibalik; membedakan pemfaktoran ulang dari perubahan perilaku; dan biarkan tim yang mengetahui konteks bisnis memutuskan utang mana yang harus dibayar.
Tugas aplikasi
Pilih fungsi dari basis kode Anda yang terlihat panjang atau rumit bagi Anda. Tes cetak pertama yang menangkap perilakunya saat ini dengan templat "jaring pengaman" dan melihat apakah semuanya lulus. Kemudian mintalah fungsi tersebut difaktorkan ulang dalam satu cara (misalnya membelah menjadi dua) dengan pola "transformasi satu langkah yang mempertahankan perilaku" dan menjalankan pengujian lagi. Jika ujian gagal, cari tahu alasannya; Jika tidak rusak sama sekali, baca perbedaannya baris demi baris untuk memastikan bahwa perilaku tersebut memang dipertahankan.
daftar periksa
- [] Saya tahu bahwa pemfaktoran ulang tidak boleh mengubah perilaku dan ada tes untuk membuktikannya.
- [] Saya sedang menyiapkan jaring pengaman yang menangkap perilaku saat ini sebelum melakukan refaktorisasi.
- [ ] Saya ingin transformasi kecil dalam satu langkah dari AI, bukan transformasi besar yang hanya terjadi satu kali saja.
- [] Setelah setiap langkah saya menjalankan tes dan membaca perbedaannya.
- [ ] Saya terus melakukan refactoring PR secara terpisah dari PR perubahan perilaku.
- [ ] Saya memprioritaskan utang teknis dengan konteks bisnis, bukan mencoba menghilangkannya begitu saja.