Bagi banyak tim, refactoring itu menyebalkan. Karena jika Anda melakukan refactoring, Anda tidak mengembangkan produk utama, dan jika Anda tidak melakukannya, hutang teknis proyek bertambah. Pada titik tertentu, tim berpikir: "Mari kita bedakan antara refactoring dan pengembangan dan alokasikan, misalnya, 20% dari jam kerja kita, dan sisa waktu kita akan terus terlibat dalam pengembangan!" Gagasan ini tidak buruk, satu-satunya hal adalah bahwa untuk setiap 100 jam pengembangan Anda tidak akan pernah mendapatkan 20 jam murni refactoring. Karena "pengembangan" tidak hanya bekerja dengan kode.
Jika kita berbicara tentang tim yang matang, daripada tim mini yang dikompres menjadi titik materi untuk 3-5 orang, maka "pengembangan" mencakup seluruh kegiatan tim yang berbeda, selain dari penulisan kode. Dalam "pengembangan", Anda dapat menulis rapat yang tidak begitu dicintai oleh banyak orang, bekerja dengan dokumentasi, mengelola laporan di task manager, dan sebagainya. Semua ini memakan sekitar 30% dari jam tangan kami yang dialokasikan untuk pengembangan. Dan entah bagaimana, secara tidak mencolok, ternyata daripada gambar "80 jam kode, 20 jam refactoring", kita mendapatkan angka yang tidak sedap dipandang ~ 13 jam untuk, secara langsung, refactoring itu sendiri, karena segala sesuatu yang lain diserap oleh kegiatan lain.
Di bawah ini kami akan memberi tahu Anda cara menggabungkan pengembangan dengan refactoring sehingga utang teknis proyek tidak tumbuh seperti bola salju, tetapi juga berbicara tentang distribusi waktu dan prioritas yang benar.
Mengapa refactoring menyebabkan begitu banyak masalah? Pertama-tama, karena fakta bahwa tim tidak dapat secara memadai mengevaluasi sumber daya mereka sendiri dan menggabungkan proses ini dengan pengembangan. Tampaknya bagi orang-orang bahwa jika hari kerja mereka adalah 8 jam sehari (40 per minggu), maka semua 40 jam mereka seharusnya terlibat dalam pembangunan. Ini tidak benar.
Seluruh proses pengembangan dapat dibagi menjadi dua bagian: ini adalah kegiatan sampingan dan segala sesuatu yang berhubungan langsung dengan kode.
Seperti inilah distribusi waktu dari salah satu tim pengembang kamiPembaca mungkin memiliki pertanyaan yang masuk akal: "bagaimana Anda membangun diagram ini?" dan sekarang kami akan mencoba memberikan jawaban. Data tidak diambil dari langit-langit, tetapi berdasarkan statistik internal kami. Pengembang kami melacak aktivitas mereka di Jira. Setiap worklog pribadi seperti itu terdiri dari empat bagian: tinjauan kode, diskusi teknis, tiket khusus, dan "segalanya". Berkat klasifikasi yang cukup sederhana dan transparan ini, kami membangun analisis tentang berapa banyak waktu di mana tim yang kami habiskan untuk setiap aspek pengembangan. Jika sepertiga dari semua waktu kerja jatuh ke rapat, stand-up dan ulasan - semuanya berada dalam kisaran normal. Jika lebih dari 33% dihabiskan untuk kegiatan ini, maka tim memiliki masalah dan perlu ditangani.
Tampaknya tidak ada tangkapan dan semuanya logis, tetapi bagaimana kita memasukkan refactoring ke dalam cerita ini? Nyatakan "bulan refactoring" dan skor untuk pengembangan? Namun, setiap produk komersial memiliki jadwal sendiri, yang sangat tidak diinginkan untuk keluar. Tetap refactoring seperti rawa: jika Anda mulai menanganinya, maka sulit untuk berhenti, Anda tertarik ke bawah ini. Refactoring menggeser fokus perhatian tim pada dirinya sendiri, dan kami mendapatkan beberapa bias mengerikan menuju "menertibkan segala sesuatu" dalam kode yang sudah ditulis alih-alih memindahkan proyek ke masa depan yang lebih cerah. Lantas bagaimana cara mendistribusikan waktu?
Slide berikut memberikan beberapa jawaban:
Simpan log waktu, ini sangat bergunaRapat dan ulasan tetap tidak tersentuh, karena kami percaya bahwa kegiatan ini dioptimalkan sebanyak mungkin dan dijaga agar tetap minimum (mereka yang bekerja dalam tim di mana pertemuan dan tinjauan kode memakan waktu 70% dari waktu akan mengkonfirmasi kata-kata kami). Jadi, kami meluangkan waktu untuk memperbaiki kode dan perbaikan bug dari pengembangan. Dan di sini kita sekali lagi menerapkan pendekatan “satu dan dua pertiga” dan membagi jam kerja yang diterima oleh kita menjadi “refactoring” dan “bug”, dengan jelas memisahkan konsep-konsep ini. Model seperti itu layak dan memungkinkan Anda menemukan waktu untuk memulihkan ketertiban proyek, setidaknya tanpa menambah hutang teknis. Jika kita menggigit terlalu banyak jam "pengembangan", proyek akan macet.
Kami mendekati proses refactoring dengan benar
Misalkan Anda memutuskan untuk melakukan refactor alih-alih menulis ulang proyek dari awal. Tetapi di sini Anda tidak dapat mengambil yang pertama dan refactor seperti di tentara, "dari sini untuk makan siang." Karena sumber daya kita terbatas dan tujuan kita adalah untuk menghentikan pertumbuhan utang teknis (dan idealnya mencapai pengurangan dalam ukurannya), kita harus mendekati tugas ini dengan masuk akal.
Solusi terbaik tampaknya memungkinkan pemimpin tim atau manajer pengembangan lain untuk menentukan ruang lingkup pekerjaan, menetapkan tugas dan melanjutkan dengan refactoring. Tetapi opsi ini memiliki kelemahan serius. Timlid adalah konduktor tim kami, tetapi masalah musisi lokal tidak selalu jelas bagi konduktor. Jika Anda adalah pendukung vertikal yang kaku dan model di mana satu orang akan memutuskan bagaimana refactoring akan terjadi, maka Anda secara sukarela duduk di KAMAZ yang terbakar, yang dengan rem yang patah mengalir dari gunung ke jurang.
Pengalaman kami menunjukkan bahwa versi yang kuat dari pengembangan acara adalah definisi kolektif dari berbagai arah refactoring, yaitu, pengembang harus mengambil bagian dalam menyusun daftar pekerjaan masa depan. Hanya penulis langsung kode yang dapat dengan jujur mengakui apakah bagian ini cukup ditutup atau karena kurangnya waktu, berbagai kruk ditumpuk di sana. Selain itu, para pengembanglah yang berada di ujung tombak teknologi dan dapat menilai dengan masuk akal elemen mana dari suatu proyek yang perlu di refactored dan mana yang tidak boleh disentuh.
Bagi kami sendiri, kami datang dengan pendekatan ini: masing-masing pengembang mengingat titik-titik tipis pada proyek dan menulis kartu tentang apa yang perlu dilakukan untuk membuatnya lebih baik. Pada kartu ini maka tugas akan ditentukan. Benar, ada nuansa: setelah kartu pertama diterima dalam gaya "melakukannya dengan baik" tanpa konteks apa pun, kami mulai menuntut konteks ini dalam bentuk terkompresi.
Kartu yang samaTetapi mendefinisikan tugas tidak cukup untuk memulai implementasinya. Oleh karena itu, daftar periksa harus dikompilasi untuk setiap kartu tersebut, yang menjawab serangkaian pertanyaan sederhana seperti "Apakah kita perlu melakukan sesuatu secara paralel?" atau "Apakah ada faktor yang mencegah kita menyelesaikan tugas ini?" Setelah mengisi daftar periksa seperti itu, pengembang menerima daftar spesifik dari semua masalah yang mungkin terjadi dan pemblokir yang perlu dipecahkan pada tahap pekerjaan persiapan.
Langkah wajib lainnya adalah menentukan siapa yang berada di area mana dari proyek yang paling tahu. Ini akan mengoptimalkan proses refactoring dan memberi anggota tim tugas di bidang-bidang di mana mereka dapat membuktikan diri mereka sendiri. Benar, suatu hari kami dihadapkan pada situasi di mana satu setengah orang biasanya memahami satu aspek proyek, tetapi bahkan masalah ini dapat diselesaikan. Untuk menghilangkan kekosongan informasi, pengembang yang masih “menggeledah” di area tempat anggota tim lainnya lewat, harus berbagi pengetahuan mereka. Ini bisa berupa dokumentasi, semacam presentasi mini, bahkan video dengan penjelasan kodenya. Penting untuk menyampaikan informasi kepada kolega dan memastikan bahwa ada bintik hitam sesedikit mungkin.
Dan akhirnya, tim harus dengan jelas menjawab pertanyaan "berapa besar hutang teknis kami?" Nilai seperti "nilai C", "dapat diterima", "lima dari sepuluh", "Anda bisa hidup" tidak lagi bekerja. Sebelumnya, kami menjawab "satu dari sepuluh" pada pertanyaan serupa dari stasiun layanan untuk salah satu proyek, dan ketika kami mengubah jumlah utang teknis menjadi angka, kami mendapat 650 jam. Itu aneh. Hanya jawaban yang jelas untuk pertanyaan ini yang akan membantu menilai lingkup pekerjaan yang akan datang. Ini juga penting karena tugas-tugas "tanpa akhir" membunuh motivasi anggota tim, serta membuat marah bisnis: baik pengembang dan manajemen harus melihat beberapa titik akhir nyata yang akan diperjuangkan tim.
Prioritas
Setelah kita menentukan bagian depan pekerjaan, kita perlu menggabungkan refactoring dengan pengembangan. Jelas, kami tidak dapat menghentikan fitur menggergaji di berbagai bagian proyek atau mengalokasikan waktu khusus untuk acara ini.
Di sinilah bagian yang paling sulit dimulai. Tim pengembang harus secara bijaksana menentukan di mana saat-saat pengembangan lebih penting dan di mana refactoring penting, terutama ketika beberapa fitur sedang digergaji tepat pada titik ini dalam kode. Mungkin, setelah refactoring, pengembangan lebih lanjut akan lebih mudah, dan dalam beberapa kasus kami dapat menyelesaikan fitur kami dan hanya kemudian refactor. Kami berkomunikasi dengan produk, memperdebatkan keputusan dan menyepakati apa yang akan dilakukan. Misalnya: "Mari kita refactor pertama - bukan hanya karena kita merasa menyukainya, tetapi karena total istilah akan lebih sedikit pada akhirnya."
Yang paling penting adalah jangan lupa bahwa tujuan kita adalah mengembangkan produk, dan tidak menulis kode yang sempurna demi kode yang sempurna atau penghapusan utang teknis secara lengkap. Pengembangan harus sepenuhnya memadai dalam hal ini: jika refactoring sekarang melukai tugas pengembangan bisnis kami, maka kami selesai menulis sepotong kode baru, dan hanya kemudian kami memperbaiki yang lama. Jika keadaan mengatakan bahwa akan lebih menguntungkan bagi proyek untuk memperbaiki bagian ini (tidak peduli seberapa mengerikan bagian depan pekerjaan itu), karena pekerjaan lebih lanjut akan lebih sederhana dan lebih menyenangkan, maka kita perlu melakukan refactor.
Pendekatan ini sangat cocok dengan model manajemen vertikal dan kadang-kadang Anda akan menghadapi situasi ketika Anda harus mempertahankan keputusan Anda di depan pelanggan. Tetapi sebaliknya tidak ada.
Apa yang kita dapatkan sebagai hasilnya
Dengan pendekatan yang dijelaskan, kami secara organik mengintegrasikan proses refactoring ke dalam perkembangan saat ini, mengurangi ukuran (atau menghentikan pertumbuhan) hutang teknis, dan semua ini tanpa ada korban besar.
Ya, demi refactoring, Anda harus mengurangi waktu untuk mengembangkan fitur baru, yang akan menambah waktu, tetapi pilihannya kecil: Anda refactor bersamaan dengan pengembangan, atau cepat atau lambat datang ke tumpukan kruk, masalah dan bug yang akan lebih mudah untuk menulis ulang proyek dari awal. Jadi jika Anda menghargai pekerjaan tim Anda, Anda harus tetap berpikir tentang refactoring daripada menulis ulang di masa depan.
Bahan yang berguna:1. Laporan Alexey Kataev tentang refactoring: contoh yang lebih praktis, serta kisah menakjubkan manajer Gleb, yang tidak ingin melakukan refactor, namun ...
2.
Peraturan kami untuk diskusi tugas3.
Ulasan kode checklist kami