Sebuah tim mewarisi modul penagihan yang tidak sepenuhnya dipahami oleh siapa pun. Modul tersebut tidak memiliki pengujian yang melindungi perilaku yang ada. Sebuah sprint diusulkan untuk "membersihkannya", dan rencananya adalah menulis ulang inti modul dalam struktur baru. Tidak ada yang bisa memastikan bagaimana mereka akan tahu bahwa versi baru tersebut masih menagih pelanggan dengan benar.
Ini adalah skenario ilustratif, bukan insiden yang terdokumentasi. Ini menggambarkan kesenjangan yang harus ditutup oleh proyek pelatihan refactoring: para insinyur yang dapat melihat bahwa kode tersebut berantakan, tetapi belum dapat merencanakan perbaikan yang terbatas dan menunjukkan bahwa perilaku tersebut tetap terjaga.
Panduan ini ditujukan untuk pimpinan pemberdayaan teknik dan manajer teknik. Panduan ini mencakup cara mendeskripsikan masalah kinerja, mendiagnosis kesenjangan, merancang persiapan dan praktik, mengerjakan studi kasus, dan menilai apakah keterampilan tersebut dapat diterapkan dalam pekerjaan nyata. Ini tentang desain pelatihan. Kode, pengujian, dan aturan dalam program Anda harus divalidasi oleh insinyur senior pada tumpukan teknologi Anda sendiri.
Apa itu proyek pelatihan refactoring?
Proyek pelatihan refactoring adalah pekerjaan terstruktur pada kode lama, yang tujuannya adalah untuk membangun kemampuan serta meningkatkan kode. Peserta pelatihan merencanakan perubahan kecil dan terbatas, melindungi perilaku yang ada dengan pengujian, meningkatkan desain secara bertahap, dan menunjukkan bukti bahwa tidak ada yang rusak. Kode menjadi lebih baik, dan yang lebih penting, para insinyur mempraktikkan penilaian yang akan mereka butuhkan pada masalah teknis yang sebenarnya.
fakta cepat
| Pertanyaan | Jawaban singkat |
|---|---|
| Apa tugasnya? | Rencanakan dan validasi peningkatan kode lama yang terbatas. |
| Berapa skor Anda? | Analisis risiko, dan bukti bahwa perilaku yang ada tetap dipertahankan. |
| Apakah penulisan ulang secara menyeluruh merupakan proyek pelatihan yang baik? | Biasanya tidak. Hal itu menyembunyikan keterampilan yang sedang dilatih dan membuat perilaku yang dipelihara sulit untuk ditunjukkan. |
| Apakah kuis tentang pola refactoring sudah cukup? | Tidak. Ini menegaskan prasyarat, tetapi tidak membuktikan apakah seorang insinyur dapat merencanakan dan memvalidasi perubahan. |
| Siapa yang memvalidasi kontennya? | Seorang manajer teknik dan seorang insinyur senior yang memahami kode program. |
| Apa yang tidak bisa diperbaiki melalui pelatihan? | Kurangnya peralatan pengujian, tekanan pelepasan, kepemilikan yang tidak jelas, dan tidak ada waktu untuk pekerjaan pemeliharaan. |
| Bagaimana Anda tahu itu berhasil? | Sebuah kasus kode lama yang baru dan belum pernah dilihat sebelumnya, dinilai berdasarkan kriteria yang disepakati, dengan tindak lanjut pada pekerjaan nyata. |
1. Jelaskan masalah kinerja tersebut
Mulailah dengan tugas: rencanakan dan validasi peningkatan kode lama yang terbatas. Kata "terbatas" adalah kata kuncinya. Peserta didik memilih perubahan yang cukup kecil untuk diselesaikan, dan dapat menentukan apa yang termasuk dan tidak termasuk dalam cakupan.
Penting untuk menggunakan istilah yang tepat. Martin Fowler mendeskripsikan refactoring sebagai teknik terkontrol untuk meningkatkan desain basis kode yang sudah ada, terdiri dari transformasi kecil yang mempertahankan perilaku. Frasa "mempertahankan perilaku" adalah yang membedakan refactoring dari penulisan ulang, dan itulah yang harus ditunjukkan dalam pelatihan. Metafora hutang teknis itu sendiri Istilah ini diciptakan oleh Ward Cunningham.Dan diskusi Fowler merupakan pengingat yang berguna bahwa utang dapat diambil secara sengaja dan bijaksana, jadi tidak setiap modul yang berantakan adalah kesalahan yang harus diperbaiki.
Buku Michael Feathers tentang kode lama (legacy code) mengambil pendekatan yang sama dalam praktiknya. Deskripsi penerbitnya mengatakan bahwa buku ini mengajarkan pengembang untuk menulis pengujian yang memastikan Mereka tidak mengubah aplikasi secara tidak sengaja.dan untuk mengendalikan perangkat lunak yang ada tanpa perlu penulisan ulang sepenuhnya.
Tuliskan pernyataan kinerja dalam satu kalimat dan mintalah seorang manajer teknik untuk memeriksanya: “Dengan mempertimbangkan modul lama dan tujuan yang telah ditentukan, insinyur mengusulkan perubahan terbatas, menambahkan pengujian yang memastikan perilaku saat ini, melakukan perubahan secara bertahap, dan menunjukkan bahwa perilaku tersebut tetap terjaga.”
2. Mendiagnosis kesenjangan pembelajaran dan konteks.
Sebelum Anda membangun apa pun, bandingkan tugas yang dibutuhkan dengan apa yang Anda praktikkan dan nilai dalam aktivitas Anda saat ini. Tiga pertanyaan biasanya membedakan kesenjangan pelatihan dari hal lain:
- Apakah praktik saat ini menggunakan tugas yang sebenarnya? Jika pelatihan mencakup pola refactoring dalam slide, tetapi tidak ada yang pernah mengubah kode yang belum diuji, tidak ada yang mempraktikkan perlindungan perilaku. Jika penilaian berupa tes pilihan ganda tentang code smell, itu hanya mengukur daya ingat.
- Apa tuntutan kognitifnya? Dalam taksonomi Bloom yang telah direvisi, menilai apakah suatu perubahan aman berada pada tingkat analisis dan evaluasi, sedangkan merancang rencana dan pengujian mencapai tingkat kreasi. Pencocokan aktivitas dengan tingkatan tersebut dibahas dalam panduan kami. Mencocokkan aktivitas pembelajaran dengan Taksonomi Bloom.
- Apakah ada hal lain selain keterampilan yang menjadi penghalang? Periksa staf, peralatan, dan prosedur. Jika proses pembuatan memakan waktu satu jam, tidak akan ada yang sering menjalankan pengujian. Jika pekerjaan pemeliharaan tidak pernah dijadwalkan, para insinyur hanya akan melakukan perbaikan secara diam-diam. Laporkan penyebab yang bukan berasal dari pelatihan kepada orang-orang yang dapat memperbaikinya.
3. Merancang persiapan dan latihan yang bertujuan.
Setelah Anda mengetahui kesenjangan mana yang dapat ditutup oleh pelatihan, berikan tugas yang berbeda untuk setiap tahapannya.
Persiapan. Periksa prasyarat dengan diagnostik singkat: bagaimana kerangka kerja pengujian Anda bekerja, apa itu pengujian karakterisasi, dan bagaimana tim Anda meninjau dan menggabungkan. Pembelajaran mandiri cocok untuk tahap ini. Pemeriksaan ingatan hanya mengkonfirmasi prasyarat.
Praktek. Gunakan proyek refactoring sistematis dengan bentuk yang jelas. Mulailah dengan sampel kecil yang aman, lalu pindah ke bagian nyata namun terbatas dari basis kode Anda sendiri. Gilded Rose kata adalah titik awal yang terkenal untuk langkah pertama. README-nya, yang dikelola oleh Emily Bache, menyarankan untuk menulis pengujian sebelum mengubah kode. dan membingkai latihan ini sebagai praktik dalam mengambil langkah-langkah kecil, menjalankan pengujian sesering mungkin, dan meningkatkan desain sedikit demi sedikit. Urutan yang masuk akal untuk setiap proyek adalah: tentukan tujuan dan batasannya, tulis pengujian yang menangkap apa yang dilakukan kode saat ini, ubah satu hal pada satu waktu, jalankan pengujian setelah setiap langkah, dan catat apa yang Anda pelajari.
Umpan balik. Hubungkan umpan balik dengan keputusan, bukan dengan skor total. Pernyataan seperti “Anda telah mengekstrak logika diskon, tetapi pengujian Anda hanya mencakup skenario ideal, sehingga Anda tidak dapat melihat perubahan pembulatan” lebih bermanfaat daripada “3 dari 5”.
Masukan langsung dari instruktur atau tinjauan asinkron? Input langsung memberikan nilai paling besar ketika pilihan yang diberikan ambigu, misalnya apakah akan berhenti dan menambahkan tes yang hilang atau melanjutkan. Tinjauan asinkron sudah cukup ketika peserta didik membandingkan rencana dan tes mereka dengan versi ahli yang telah dianotasi. Banyak tim menggunakan keduanya: persiapan mandiri terlebih dahulu, kemudian sesi yang difasilitasi untuk kasus-kasus sulit.
4. Kerjakan contoh yang realistis.
Sebagai ilustrasi. Manajer teknik harus memvalidasi kasus dan kriteria jawaban sebelum digunakan.
Kasus. Sebuah fungsi lama menghitung total pesanan, termasuk diskon, pajak, dan aturan pengiriman. Fungsi ini tidak memiliki pengujian. Sebuah tim mengusulkan untuk merstruktur ulang seluruh modul penagihan agar menjadi lebih "bersih".
Tugas tersebut. Peserta didik menjelaskan apa yang akan mereka lakukan, menyebutkan bukti yang akan mereka kumpulkan, dan menyatakan informasi atau dukungan lebih lanjut apa yang mereka butuhkan.
Upaya pertama. “Saya akan membagi modul menjadi tiga layanan dan memindahkan logikanya, lalu memeriksa angkanya di lingkungan pengujian.” Pelajar tersebut memilih perubahan besar dan pengecekan manual yang terlambat. Tidak ada cara untuk mengetahui apakah versi lama dan baru sesuai pada kasus-kasus ekstrem.
Berikan masukan dan coba lagi. Peninjau bertanya apa yang dilakukan fungsi tersebut saat ini untuk keranjang kosong, diskon yang membuat total menjadi negatif, dan kasus pembulatan. Percobaan ulang meminta pelajar untuk mempersempit ruang lingkup ke satu perilaku dan untuk mengatakan bagaimana mereka akan membuktikan bahwa perilaku tersebut tidak berubah.
Upaya yang lebih baik. “Untuk saat ini, saya akan membiarkan struktur modul apa adanya. Saya akan mencatat apa yang dikembalikan oleh fungsi total pesanan hari ini untuk serangkaian input, termasuk kasus-kasus ekstrem, sebagai pengujian. Kemudian saya akan mengekstrak perhitungan diskon ke dalam fungsinya sendiri, menjalankan pengujian setelah langkah tunggal itu, dan berhenti. Saya akan mencatat bahwa aturan pengiriman memiliki perilaku yang tidak saya pahami dan akan bertanya kepada kolega sebelum mengubahnya.” Perhatikan bahwa jawaban ini membatasi perubahan, melindungi perilaku terlebih dahulu, dan menyebutkan apa yang tidak diketahui.
Mengapa setiap respons dapat dipertahankan atau tidak lengkap. Nilailah setiap upaya berdasarkan kriteria yang telah disetujui, bukan preferensi penilai. Upaya pertama mungkin merupakan arah jangka panjang yang masuk akal, tetapi tidak lengkap sebagai sebuah rencana, karena tidak mengandung bukti perilaku yang dipertahankan. Upaya yang lebih kuat bersifat kecil, dapat diperiksa, dan jujur tentang ketidakpastian.
5. Menilai kemampuan dan merencanakan transfer
Bukti kemampuan adalah kinerja pada kasus kode lama baru yang belum pernah dilihat oleh peserta didik. Beri nilai pada analisis risiko dan bukti bahwa perilaku tersebut dipertahankan. Rubrik sederhana menggunakan skala 0 hingga 2 per kriteria:
| Kriterium | Bukti yang dapat diamati |
|---|---|
| Eksekusi tugas | Merencanakan dan memvalidasi peningkatan kode lama yang terbatas, serta mencatat tindakan dan bukti di baliknya. |
| Pemikiran | Menjelaskan kendala, alternatif, dan ketidakpastian, serta memeriksa risiko dan bukti bahwa perilaku tersebut tetap terjaga. |
| Batas | Menggunakan prosedur yang telah disetujui, dan meminta bantuan jika informasi atau wewenang tidak mencukupi. |
Nilai acuan: 0 berarti tidak ada atau tidak didukung, 1 berarti sebagian dengan kelalaian yang relevan, dan 2 berarti lengkap dan dibenarkan berdasarkan kriteria yang disepakati. Definisikan kesalahan kritis secara terpisah, seperti perubahan perilaku tanpa pengujian yang dapat mendeteksinya, sehingga skor keseluruhan tidak dapat menyembunyikan satu kesalahan pun. Rubrik ini adalah usulan, bukan standar kesiapan yang telah divalidasi: sesuaikan dengan manajer teknik dan lakukan uji coba. Panduan kami untuk merancang praktik interaktif dengan umpan balik yang bermanfaat Menunjukkan cara menulis umpan balik yang terkait dengan keputusan.
Rencanakan transfer secara matang. Setelah latihan, berikan setiap insinyur tugas nyata yang kecil untuk ditangani bersama peninjau, atau jalankan retrospektif singkat tentang perubahan terbaru yang menyebabkan masalah. Periksa transfer setelah terpapar pada pekerjaan nyata, bukan langsung setelah lokakarya.
Di mana penyampaian interaktif membantu
Format interaktif membantu ketika setiap orang harus berkomitmen sebelum melihat kelompok. Dalam sesi langsung, fasilitator dapat menunjukkan cuplikan kode lama yang singkat, meminta setiap insinyur untuk mengirimkan perubahan pertama yang akan mereka buat dan bagaimana mereka akan membuktikannya aman, lalu mengungkapkan perubahan tersebut sebelum diskusi. Permintaan yang sama dapat dijalankan secara mandiri untuk persiapan. AhaSlides mendukung pembelajaran interaktif dan perpindahan antara penyampaian langsung dan mandiri. Ini adalah alat presentasi dan pembelajaran, bukan tempat untuk menjalankan atau menganalisis kode, jadi jalankan refactoring itu sendiri di lingkungan Anda. Periksa fungsi penulisan, umpan balik, atau pelaporan khusus yang Anda rencanakan untuk diandalkan terhadap alur kerja Anda sendiri. Untuk panduan tentang pemilihan format, lihat artikel kami tentang... Kapan menggunakan pembelajaran adaptif, interaktif, dan langsung?.
Ukur apa yang berubah.
Tentukan terlebih dahulu apa yang akan menunjukkan bahwa para insinyur mampu melakukan tugas tersebut. Bandingkan kualitas analisis risiko dan bukti perilaku yang terjaga pada kasus yang belum pernah dilihat sebelumnya, dengan tolok ukur. Tentukan siapa yang dilibatkan, penyebutnya, dan waktunya. Jika hasilnya membaik, periksa apa lagi yang berubah dalam periode yang sama, seperti alat pengujian baru, proses build yang lebih cepat, atau perubahan kepemilikan, sebelum memberikan penghargaan atas pelatihan tersebut.
Kendala yang mungkin masih ada
- Saatnya melakukan pekerjaan perawatan. Jika pekerjaan penagihan utang tidak pernah dijadwalkan, para insinyur terlatih tetap tidak memiliki tempat untuk menggunakan keahlian mereka.
- Peralatan pengujian. Tanpa alat uji yang dapat digunakan atau proses pembuatan yang cepat, langkah-langkah kecil dan pengecekan berkala sulit untuk dipertahankan.
- Liputan kasus. Salah satu studi kasus lama menunjukkan beberapa jenis risiko. Skor tidak menggambarkan penilaian seorang insinyur secara umum.
- Menilai kapan tidak perlu melakukan refactoring. Beberapa kode sebaiknya dibiarkan saja, diganti, atau dihentikan penggunaannya, dan keputusan itu melibatkan lebih dari sekadar keahlian.
- Transfer. Performa dalam sebuah kata tidak sama dengan performa dalam modul produksi di bawah tekanan pengiriman.
Sebutkan hal-hal ini kepada sponsor sejak dini dan rencanakan perbaikan secara terpisah. Pelatihan meningkatkan kemampuan seorang insinyur dalam merencanakan dan membuktikan sesuatu. Namun, pelatihan tidak menciptakan waktu atau peralatan yang dibutuhkan.
Pertanyaan yang sering diajukan
Apa itu proyek pelatihan refactoring?
Ini adalah praktik terstruktur pada kode lama di mana para insinyur merencanakan perubahan kecil, melindungi perilaku yang ada dengan pengujian, mengubah desain secara bertahap, dan menunjukkan bahwa tidak ada yang rusak.
Apakah penulisan ulang total merupakan cara yang baik untuk mempelajari tentang hutang teknis?
Biasanya tidak. Penulisan ulang kode itu besar, sulit divalidasi, dan menyembunyikan keterampilan yang ingin Anda kembangkan. Perubahan terbatas dengan pengujian yang menangkap perilaku saat ini membuat alasan di baliknya terlihat jelas.
Bagaimana Anda menilai apakah para insinyur dapat melakukan refactoring dengan aman?
Berikan kasus kode lama yang baru dan beri skor pada analisis risiko dan bukti bahwa perilaku tersebut dipertahankan berdasarkan kriteria yang disepakati. Kuis tentang pola refactoring hanya mengkonfirmasi prasyarat.
Apakah Anda memerlukan contoh kode program untuk pelatihan ini?
Anda membutuhkan tempat untuk berlatih dengan aman. Banyak tim memulai dengan kata publik dan kemudian beralih ke bagian kode mereka sendiri yang terbatas. Manajer teknik Anda harus mengkonfirmasi bahwa kode tersebut sesuai.
Mulai dari mana
Pilih satu jenis perubahan warisan kecil dan berulang dalam basis kode Anda. Tulis pernyataan kinerja, minta manajer teknik untuk memvalidasi kasus dan pengujian yang akan menunjukkan perilaku yang dipertahankan, dan susun rubrik tiga kriteria dengan skala 0 hingga 2 dan daftar kesalahan kritis. Uji coba dengan kelompok kecil sebelum Anda meluncurkannya.
Untuk melihat bagaimana latihan pengambilan keputusan refactoring dapat dijalankan secara langsung dengan tim Anda sendiri, dan digunakan kembali secara mandiri setelahnya, jelajahi AhaSlides.
