Unit 8 / 12

Pemfaktoran Semula dan Pengurusan Hutang Teknikal

Keuntungan:

  • Keupayaan untuk menyediakan jaringan keselamatan ujian yang menangkap tingkah laku semasa sebelum pemfaktoran semula
  • Keupayaan untuk meminta AI untuk transformasi kecil, satu langkah, memelihara tingkah laku dan mengesahkan setiap langkah
  • Keupayaan untuk mengenal pasti dan mengutamakan hutang teknikal dalam konteks perniagaan

Pemfaktoran semula ialah menambah baik struktur dalaman kod tanpa mengubah tingkah laku luarannya: menjadikannya lebih mudah dibaca, lebih mudah, lebih boleh diselenggara. Hutang teknikal, sebaliknya, ialah kompromi reka bentuk yang dibuat demi penyelesaian yang cepat dan dibayar balik "dengan faedah" dari semasa ke semasa — setiap sudut yang anda potong hari ini akan kembali sebagai kelembapan atau pepijat esok. Kecerdasan buatan ialah pembantu berkuasa yang mempercepatkan tugas pemfaktoran semula yang berulang dan mekanikal; Tetapi terdapat satu peraturan emas pemfaktoran semula, dan AI sahaja tidak dapat menjaminnya: tingkah laku tidak boleh berubah.

Dalam unit ini, kita belajar cara melakukan pemfaktoran semula yang selamat dengan AI: langkah kecil dan boleh diterbalikkan, melindungi dengan ujian, mengesan bau kod dan mengutamakan hutang teknikal. Perkara kritikal ialah ini: ujian yang lulus, bukan perkataan AI, yang membuktikan bahawa tingkah laku itu dipelihara.

Peraturan Emas Pemfaktoran Semula: Tingkah Laku Kekal Malar

Perkara yang menjadikan pemfaktoran semula berbahaya ialah mengubah tingkah laku tanpa disedari sambil berkata "Saya bertambah baik." Menggugurkan sarung tepi apabila memudahkan syarat, memecahkan tertib apabila mengubah gelung, kehilangan kesan sampingan apabila membelah fungsi—semuanya menghasilkan kod yang "nampak bersih" tetapi rosak.

Itulah sebabnya ujian adalah prasyarat untuk pemfaktoran semula: sebelum menukar, anda mesti mempunyai ujian yang menangkap gelagat sedia ada. Ujian ini adalah "jaring keselamatan"; Jika anda secara tidak sengaja memecahkan sesuatu semasa pemfaktoran semula, mereka akan memecahkan dan memberi amaran kepada anda. Jika anda tidak mempunyai ujian, tulis ujian yang membetulkan gelagat sedia ada terlebih dahulu (seperti yang kita pelajari dalam unit 5) — di sinilah AI mula melompat.

Awas: Pemfaktoran semula berbantukan AI tanpa testnet ialah salah satu sumber pepijat yang paling berbahaya. Sangat mudah untuk mengatakan "Saya memelihara tingkah laku"; Buktinya ialah ujian yang sama lulus sebelum dan selepas perubahan.

Langkah demi Langkah: Aliran Pemfaktoran Selamat

  1. Sediakan jaring keselamatan. Biarkan terdapat ujian yang menangkap tingkah laku semasa kod yang akan anda lakukan semula; Jika tidak, tuliskannya terlebih dahulu (dan lihat mereka pergi).
  2. Namakan baunya. Apakah yang anda perbaiki dan mengapa? "Fungsi ini melakukan 3 perkara", "logik yang sama berulang di 4 tempat", "nama mengelirukan".
  3. Minta langkah kecil selangkah. Minta AI untuk satu transformasi (cth. hanya "belah fungsi ini kepada separuh"), bukan untuk menulis semula keseluruhan fail.
  4. Jalankan ujian. Selepas setiap langkah. Kalau hijau teruskan, kalau merah ambil balik.
  5. Baca Diff. Sahkan baris demi baris bahawa perubahan itu sememangnya memelihara tingkah laku; Mungkin terdapat kegelisahan logik apabila mengatakan AI adalah "hanya struktur".
  6. Satukan menjadi kepingan kecil. PR pemfaktoran semula satu kali yang besar adalah berisiko dan tidak boleh disemak.

Tiga Kes Mini

Kes 1 — Fungsi 220 baris berpecah dengan selamat. Satu pasukan mempunyai fungsi pemprosesan pesanan 220 baris. 14 ujian pertama telah ditulis (dengan bantuan AI) yang menangkap tingkah laku semasa, semuanya lulus. Kemudian fungsi itu dibahagikan kepada 5 fungsi yang lebih kecil langkah demi langkah oleh AI; Ujian dijalankan selepas setiap langkah. Dua ujian telah dipecahkan dalam satu langkah — AI telah terlepas pulangan dalam kes tepi. Ujian menangkap ini dengan segera dan membetulkannya. Tanpa rangkaian, ralat boleh pergi ke pengeluaran.

Kes 2 — Bencana tanpa testnet. Pembangun lain "membersihkan" modul pengiraan tarikh yang tidak mempunyai ujian dengan AI. Kod itu kelihatan lebih baik, tetapi ia mengira tahun lompat dengan salah; Pepijat keluar dua minggu kemudian dengan aduan pelanggan. Kerugian jauh melebihi masa yang disimpan daripada pemfaktoran semula. Pengajaran: pemfaktoran semula tanpa ujian adalah satu perjudian.

Kes 3 — Pengutamaan hutang teknikal. Satu pasukan memberi AI tunggakan sebanyak 30 atau lebih mata "boleh diperbaiki" dan masing-masing mendapat markah pada paksi "kekerapan perubahan × risiko × usaha". Dalam jadual yang terhasil, modul hodoh yang jarang disentuh sebenarnya adalah keutamaan yang rendah, manakala modul kerumitan sederhana yang kerap berubah adalah keutamaan yang tinggi. Pasukan itu mengarahkan tenaganya ke tempat yang betul.

Empat Templat Boleh Disalin

Pengesanan bau kod dan keutamaan:

Senaraikan "bau" calon pemfaktoran semula dalam kod ini: fungsi panjang, ulangi (Pelanggaran KERING), nama mengelirukan, keadaan bersarang dalam, kesan sampingan tersembunyi, nombor ajaib. Untuk setiap: lokasi, sebab masalah, langkah kecil yang dicadangkan, anggaran risiko (rendah/sederhana/tinggi). JANGAN TUKAR kod lagi, rancang sahaja.{{kod}}

Satu langkah, transformasi memelihara tingkah laku:

HANYA lakukan ini: {{penukaran tunggal, mis. Bahagikan fungsi ini kepada 3 fungsi bernama yang lebih kecil}}. TUKAR tingkah laku yang boleh dilihat, tandatangan dan nilai pulangan. Tulis dalam 1 ayat mengapa semua yang anda ubah mengekalkan tingkah laku.{{kod}}

Jaring keselamatan sebelum refactor (ujian pencirian):

Tulis ujian yang menangkap kelakuan SEMASA fungsi ini (betul atau tidak); matlamatnya adalah untuk menangkap jika tingkah laku berubah semasa pemfaktoran semula. Sertakan entri tipikal + tepi. Tulis jangkaan berdasarkan output semasa fungsi.{{function}}

Penjanaan rekod hutang teknikal (tunggak):

Tuangkan senarai bau berikut ke dalam jadual keutamaan: bahan, kawasan terjejas, kekerapan perubahan (pengetahuan saya: {{...}}), risiko, anggaran usaha, keutamaan yang disyorkan. Letakkan impak tinggi + usaha rendah di bahagian atas. {{senarai_bau}}

Gesaan lemah / Gesaan kuat

Lemah: "Bersihkan kod ini dan jadikan ia lebih baik."
Kuat: "Pisah fungsi 90 baris ini kepada 3 fungsi yang lebih kecil dengan tanggungjawab tunggal, tanpa mengubah tingkah laku dan tandatangan luarannya. Kekalkan kesan sampingan (tulisan DB) dalam susunan semasa. Saya mempunyai ujian, tingkah laku harus kekal sama. Berikan perbezaan dan jelaskan dalam satu ayat mengapa setiap pemisahan adalah memelihara tingkah laku. [kod]"

Versi berkuasa; Ia memerlukan satu transformasi khusus, secara eksplisit mengenakan kekangan tingkah laku dan tandatangan, dan menuntut justifikasi. Permintaan yang tidak jelas seperti "berbuat lebih baik" membawa kepada perubahan yang tidak terkawal dan berisiko.

Jenis pemfaktoran semula

Kebolehpercayaan AI

Prasyarat

menamakan semula

tinggi

Adakah skopnya betul?

Pembahagian fungsi

sederhana tinggi

Testnet adalah satu kemestian

Berkongsi ulangan

sederhana

Perbezaan tingkah laku mungkin disembunyikan

Algoritma/perubahan struktur

rendah

Ujian meluas + pengesahan manusia

Penyusunan semula seni bina

rendah

Diterajui manusia, disokong AI

Menguruskan Hutang Teknikal, Bukan Menetapkannya Semula

Hutang teknikal tidak semuanya buruk; Kadang-kadang meminjam secara sedar (untuk memenuhi penghantaran) adalah keputusan yang tepat. Matlamatnya bukan untuk menghapuskan hutang, tetapi untuk menjadikannya kelihatan dan terurus. AI pantas mengesan dan mengutamakan hutang, tetapi memutuskan "hutang mana yang harus dibayar dan mana yang harus ditinggalkan" memerlukan konteks perniagaan: berapa kerap modul ini berubah, berapa ramai orang yang mempengaruhinya, apakah risikonya? Keputusan ini dibuat oleh pasukan yang mengetahui asas kod dan produk; AI hanya menjelaskan pilihan.

Petua: Pastikan PR pemfaktoran semula anda berasingan daripada PR yang melibatkan perubahan tingkah laku. Mampu mengatakan "PR ini hanyalah pemfaktoran semula, tingkah laku adalah sama" memudahkan untuk menyiasat dan membolehkan anda dengan cepat mempersempit punca jika masalah timbul.

Kesilapan biasa

  • Pemfaktoran semula tanpa testnet. Anda tidak mempunyai apa-apa untuk membuktikan bahawa tingkah laku itu dipelihara.
  • Ia bermaksud "kosongkan keseluruhan fail". Perubahan besar dan tidak terkawal menyembunyikan ralat dan tidak boleh diperiksa.
  • Menerima Diff tanpa membacanya. AI mungkin telah tergelincir beberapa logik apabila ia berkata "hanya struktur".
  • Pemfaktoran semula yang mengelirukan dengan perubahan tingkah laku. Melakukan kedua-duanya dalam PR yang sama menjadikan pengesanan punca menjadi mustahil.
  • Cuba membaiki setiap bau. Kod hodoh yang jarang berubah selalunya mempunyai keutamaan yang rendah; Peruntukkan tenaga ke tempat yang kerap berubah.

Secara ringkasnya

Satu-satunya peraturan pemfaktoran semula ialah tingkah laku kekal malar, dan buktinya ialah ujian. AI berkuasa dalam mengesan bau kod, transformasi satu langkah dan mengutamakan hutang teknikal; tetapi anda perlu menyediakan jaring keselamatan, jalankan ujian dan baca perbezaan selepas setiap langkah. Ambil langkah kecil yang boleh diterbalikkan; membezakan pemfaktoran semula daripada perubahan tingkah laku; dan biarkan pasukan yang mengetahui konteks perniagaan memutuskan hutang yang perlu dibayar.

Tugasan permohonan

Pilih fungsi daripada pangkalan kod anda yang kelihatan panjang atau rumit kepada anda. Ujian cetakan pertama yang menangkap gelagat semasanya dengan templat "jaring keselamatan" dan lihat jika semuanya lulus. Kemudian minta fungsi difaktorkan semula dalam satu cara (cth. membelah separuh) dengan corak "satu langkah, transformasi memelihara tingkah laku" dan jalankan ujian sekali lagi. Jika ujian gagal, ketahui sebabnya; Jika ia tidak pecah sama sekali, baca diff baris demi baris untuk mengesahkan bahawa tingkah laku itu memang terpelihara.

senarai semak

  • [ ] Saya tahu bahawa pemfaktoran semula tidak seharusnya mengubah tingkah laku dan terdapat ujian untuk membuktikannya.
  • [ ] Saya sedang menyediakan jaring keselamatan yang menangkap tingkah laku semasa sebelum refactor.
  • [ ] Saya mahukan transformasi kecil satu langkah daripada AI, bukan perubahan besar.
  • [ ] Selepas setiap langkah saya menjalankan ujian dan membaca perbezaannya.
  • [ ] Saya terus memfaktorkan semula PR secara berasingan daripada perubahan tingkah laku PR.
  • [ ] Saya mengutamakan hutang teknikal dengan konteks perniagaan, bukan cuba menyifar secara membabi buta.