Bagaimana cara saya menangani refactoring yang membutuhkan waktu lebih dari satu sprint?

Saya bekerja dengan basis kode yang lebih dari 500 ribu baris kode. Sangat perlu refactoring. Telah ada upaya refactoring yang diidentifikasi yang akan memakan waktu lebih lama dari sprint dua minggu normal. Ini tidak dapat dipecah menjadi tugas yang lebih kecil seperti yang saya lihat disarankan dalam jawaban lain di situs ini. Produk perlu bekerja pada akhir iterasi, dan refactoring parsial akan membuat sistem dalam keadaan tidak dapat digunakan karena ketergantungan antar item sangat mengerikan. Jadi apa cara terbaik untuk mendekati rintangan ini? Sekali lagi saya sebutkan, memecahnya menjadi potongan-potongan kecil bukanlah pilihan, yang telah dilakukan.

Pembaruan: Orang-orang tampaknya membutuhkan penjelasan mengapa ini tidak bisa masuk dalam sprint 2 minggu. Ada lebih banyak yang terlibat dalam sprint daripada hanya menulis kode. Kami memiliki kebijakan tanpa kode tanpa tes. Kebijakan itu tidak selalu ada dan sebagian besar basis kode tidak memilikinya. Juga beberapa tes integrasi kami masih berupa tes manual. Masalahnya bukan bahwa refactoring itu sendiri sangat besar. Dengan fakta bahwa perubahan kecil berdampak pada banyak bagian sistem, dan kita perlu memastikan bahwa bagian-bagian itu masih beroperasi dengan benar.

Kami tidak dapat menunda atau memperpanjang sprint karena kami memiliki hotfix bulanan. Jadi, perubahan yang melampaui sprint tidak bisa menghentikan pekerjaan lain yang ditambahkan ke perbaikan terbaru.

Refactoring vs Redesign: Hanya karena proses pengembangan kami tidak cukup efektif untuk menangani refactoring ini dalam siklus dua minggu tidak menjamin pengubahan nama menjadi redesign. Saya ingin percaya bahwa di masa depan kita bisa menyelesaikan tugas yang sama persis dalam siklus dua minggu saat proses kita membaik. Kode yang dimaksud di sini belum harus berubah dalam waktu yang sangat lama, dan cukup stabil. Sekarang, ketika arah perusahaan menjadi lebih mudah beradaptasi terhadap perubahan, kami ingin bagian basis kode ini dapat beradaptasi seperti yang lainnya. Yang membutuhkan refactoring itu. Berdasarkan jawaban di sini, menjadi jelas bahwa ada perancah yang hilang yang diperlukan untuk membuat refactoring ini bekerja dalam kerangka waktu sprint normal.

Menjawab:

Saya akan melakukan pendekatan cabang dan penggabungan yang disarankan Corbin March pertama kali sehingga kami dapat mempelajari lebih lanjut tentang bidang masalah ini dan cara mengidentifikasi tes yang hilang. Saya pikir untuk maju, kita harus mengambil pendekatan yang disarankan Buhb untuk mengidentifikasi area yang tidak lulus tes dan mengimplementasikannya terlebih dahulu, kemudian melakukan refactoring. Ini akan memungkinkan kita untuk mempertahankan siklus sprint dua minggu yang normal, seperti yang dikatakan banyak orang di sini seharusnya selalu menjadi kasus untuk refactoring.

Jika Anda memiliki kemewahan menunda refactoring, saya sarankan memfokuskan iterasi mendatang pada menambahkan unit test dan tes integrasi otomatis ke titik di mana Anda dapat dengan nyaman memperbaiki basis kode, dan kemudian refactor dalam sprint tunggal.

Saran saya:

1. Buat cabang
2. Gabungkan setiap hari dari bagasi ke cabang Anda dan selesaikan konflik.
3. Bekerja sampai selesai. Cabang Anda mungkin berada di luar pengembangan inti untuk beberapa sprint.
4. Gabungkan kembali ke bagasi.

Tidak ada cara untuk mengelak dari kenyataan bahwa itu mungkin akan menjadi jelek. Aku tidak iri padamu. Dalam pengalaman saya, ketika Anda secara drastis mengubah suatu proyek, lebih mudah untuk menggabungkan pengembangan yang sedang berlangsung ke dalam paradigma baru versus entah bagaimana menggabungkan paradigma baru menjadi batang yang sekarang berubah setelah semuanya selesai. Tetap saja, itu akan terasa sakit.

Tidak setiap tugas dapat dilakukan dalam sprint 2 minggu (artifisial), jadi diperlukan akal sehat. Jika tidak dapat dipecah lagi, dan itu harus dilakukan, teruskan saja dan lakukan. Prosesnya tidak lebih penting daripada hasil akhirnya, dan harus dilihat sebagai pedoman daripada hukum yang tidak boleh dilanggar.

Lakukan sprint 3, 4 atau 5 minggu. Siapa peduli? Anda jelas yakin bahwa tidak ada yang bisa dilakukan dalam jangka waktu yang lebih pendek, jadi berhentilah melawannya.

Hanya saja, jangan beri tahu teman Anda di The Royal Society of Blind Agile Adherance.

Saya sarankan memulai dengan buku Bekerja Efektif dengan Legacy Code , oleh Michael Feathers. Ia membahas berbagai teknik untuk mengurangi cakupan perubahan gaya refactoring.

Di toko kami, ketika kami memiliki tugas refactoring atau penulisan ulang yang besar yang tidak dapat diselesaikan di jendela rilis, kami membiarkan fungsionalitas apa adanya di dalam sistem. Tapi, kita mulai pada fungsi lego-blok yang baru dan sudah di-refactored sesuai waktu. Akhirnya, kita sampai pada keadaan di mana kita memiliki cukup blok-lego, bahwa sprint menyediakan waktu yang cukup untuk menghubungkan blok-blok lego ke dalam aplikasi dan menyalakannya untuk para pengguna.

Lebih singkatnya, kami memecah atau mengolah fungsi besar menggunakan nama baru. Kemudian, pada akhirnya, kami menggunakan pekerjaan kami yang telah diganti nama dan dire-refoured alih-alih kode lama yang jahat.

Dedikasikan satu sprint untuk mencari tahu bagaimana menjaga kode berfungsi dengan baik mid-refactor. Ini dapat berupa metode dan kelas yang sudah usang, pembungkus, adaptor, dan sejenisnya. Refactoring Anda mungkin membuat kode lebih kotor untuk waktu yang singkat agar jangka panjang menjadi lebih bersih; tidak apa-apa. Sekarang Anda mengatakan itu tidak bisa dilakukan. Saya pikir itu tidak benar - pikirkan tentang seperti apa proses Anda jika itu bisa dilakukan, pikirkan langkah apa yang dapat Anda ambil untuk membuatnya. Kemudian menyelam.

Memberi +1 pada jawaban Corbin March, itulah yang saya pikirkan. Kedengarannya seperti basis kode Anda agak jelek dan butuh lebih dari satu siklus sprint untuk membersihkannya.
Jadi seperti kata Corbin,

1. cabang itu menjadi "proyek refactoring"
2. uji perubahan cabang Anda
3. promosikan ke lingkungan pengujian Anda untuk pengujian QA
4. secara bertahap menggabungkannya kembali ke bagasi sampai refactoring selesai.

Saya yakin Anda tidak akan memiliki masalah menjual ini ke manajer dev Anda, jika PM Anda mengalami kesulitan melihatnya kemudian jelaskan kepada mereka bahwa Roma tidak dibangun dalam sehari dan membersihkan semua sampah yang dibuang ke Roma jalanan juga tidak akan dilakukan dalam sehari. Refactoring akan memakan waktu cukup lama tetapi pada akhirnya akan sangat bermanfaat dalam hal perawatan yang lebih mudah, rilis peningkatan yang lebih cepat, lebih sedikit tiket produksi, dan SLA yang lebih terpenuhi.

Meskipun pendesainan ulang yang benar-benar ingin Anda lakukan adalah tugas besar, apakah mungkin untuk memperbaiki bagian yang lebih kecil untuk memecahkan / memisahkan ketergantungan individu? Anda tahu - ketika ragu, tambahkan tipuan. Masing-masing dari decoupling ini harus menjadi tugas yang lebih kecil daripada tugas besar yang tidak bisa Anda selesaikan.

Setelah dependensi dihapus, Anda harus dapat memecah tugas-tugas refactoring yang tersisa untuk diperoleh dalam sprint.

Dalam proyek yang saya kerjakan saat ini, kami menggunakan sprint 4 minggu. Dan kadang-kadang kita tidak bisa menyelesaikan cerita pengguna dan kita hanya memulai kembali selama sprint berikut.

Namun, IMHO mungkin untuk memecah refactoring menjadi cerita yang lebih kecil yang muat dalam sprint 4 minggu. Jika Anda tidak dapat membawa kode ke dalam kondisi yang konsisten dalam waktu 4 minggu, saya merasa bahwa Anda sedang menulis ulang aplikasi Anda daripada refactoring.

Saya merekomendasikan bahwa ketika tugas tertentu akan memakan waktu lebih lama dari siklus sprint 2 minggu, tugas tersebut dijadwalkan untuk waktu lain. Tim Anda telah mengidentifikasi perlunya refactoring dan itu penting. Terkadang, tidak ada pilihan lain ... dan, ya, itu payah.

Ketika tiba saatnya untuk memulai refactoring, Anda hanya akan menangguhkan sprint normal. Anda tidak punya pilihan. Gunakan kontrol versi pintar - cabang, refactor, tes, gabung. Selalu ada titik waktu di mana refactoring beberapa proyek besar lebih diprioritaskan daripada fitur. Jika memungkinkan, saya juga akan mencoba untuk memisahkan masalah untuk fleksibilitas yang lebih baik.

Baru-baru ini mengalami masalah yang sama dengan bagian basis kode kami (yang juga sedikit lebih besar), saya harap saya dapat berbagi beberapa wawasan dengan Anda. Dalam situasi saya, basis kode telah dikembangkan oleh tim lain, jadi tidak ada dari pengembang asli yang terlibat dalam refactoring ini. Pengalaman saya dengan basis kode sekitar 1 tahun, dan pengembang lain ditugaskan 2 tahun.

Izinkan saya dua catatan kecil mengenai jawaban lain di sini:

• Bercabang akan membantu Anda membangun taman bermain untuk diri sendiri, tetapi jangan pernah menggabungkan perubahan Anda menjadi trunk dalam satu perubahan besar. Anda akan mendapat masalah serius dengan anggota tim lainnya.
• Anda perlu melakukannya secara bertahap, dan itu bisa dilakukan. Tidak ada alasan. Baca Bekerja Efisien dengan sampul Kode Legacy . Baca lagi.
• Berpikir Anda bisa melakukannya satu langkah besar adalah kesalahan. Meskipun tampaknya lebih banyak pekerjaan, melakukannya secara bertahap lebih mudah untuk dikelola.

Tampaknya "tidak masuk dalam reservasi" selama dua minggu atau lebih tidak akan luput dari perhatian. Anda perlu memastikan bahwa Anda didukung oleh manajemen proyek, dan bahkan yang lebih penting adalah tim. Jika tim tidak berkomitmen untuk refactoring ini (dan ini berarti, lakukan sekarang, jangan di masa depan yang jauh), Anda akan mendapat masalah.

Jangan lakukan itu sendiri, gunakan pemrograman berpasangan. Ini tidak sepenuhnya berarti Anda harus duduk di depan keyboard yang sama sepanjang waktu, tetapi dapat menangani tugas-tugas kecil dan sempit (misalnya menulis tes yang menangkap perilaku kelas ini) secara individual.

Lakukan Scratch Refactoring dan perlakukan seperti itu. (Semacam refactoring prototipe "dibuang", bit "dibuang" itu penting!) Sejujurnya, kecil kemungkinan Anda mengetahui semua implikasi yang akan dimiliki refactoring Anda. Refactoring awal akan membantu Anda dalam hal-hal tertentu:

• Anda akan menemukan potongan-potongan sistem yang Anda tidak pernah tahu mereka ada.
• Anda akan memiliki pandangan yang jauh lebih baik tentang bagaimana modul saling berhubungan
• Anda akan menemukan cara baru untuk mengelompokkan sistem Anda ke dalam modul, kemungkinan jauh berbeda dari pemahaman Anda saat ini. Diskusikan wawasan dengan pasangan Anda. Cobalah untuk menyaring pandangan baru Anda. Tulis whitepaper arsitektur pendek (atau gambar diagram) yang mengatakan di mana benda-benda saat ini dan di mana barang-barang itu seharusnya berada secara logis.

Ketika Anda telah melakukan refactoring awal Anda, saya harap Anda akan menemukan bahwa Anda tidak bisa begitu saja mengubah segalanya. Anda akan merasa buruk, itu hanya kekacauan besar dan Anda tidak bisa hanya membalik saklar dan membuatnya bekerja. Inilah yang terjadi pada saya, mungkin berbeda dalam situasi Anda.

Namun, saya dan mitra saya memiliki pemahaman yang jauh lebih baik tentang sistem kami. Sekarang kami dapat mengidentifikasi refactor / desain ulang individual, lebih kecil (meskipun masih besar). Kami menangkap visi kami tentang sistem dalam diagram dan membaginya dengan tim, bersama dengan item jaminan yang kami buat untuk mengimplementasikan visi tersebut. Diberdayakan oleh konsensus bersama, kami memutuskan item mana yang akan kami terapkan selama iterasi berikutnya.

Satu hal terakhir yang membantu kami menggunakan papan tulis besar. Ada terlalu banyak hal untuk diingat. Sangat penting untuk membuat catatan. Tulis diri Anda sendiri sebuah catatan penjelasan di akhir hari, menangkap apa yang telah Anda lakukan hari ini dan ingin Anda lakukan besok. Ini membantu bersantai di saat-saat besar, dan Anda perlu waktu santai jika Anda ingin mengikuti tugas. Semoga berhasil!

Mulai jendela pemeliharaan selama tidak ada pengembangan lebih lanjut dilakukan. Lakukan desain ulang, lalu lanjutkan sprint pengembangan.

Kami memiliki dua jenis pekerjaan:

1. Jam kerja pria
2. Jenius bekerja

Refactoring biasanya terdiri dari jenis pekerjaan pertama, karena banyak metode yang sudah diketahui oleh pengembang seperti KERING , SRP , OCP , DI , dll. Jadi ketika sebuah proyek membutuhkan waktu dua bulan untuk di refactored, itu hanya membutuhkan waktu dua bulan , ada tidak ada jalan lain. Jadi, saran saya adalah untuk tidak memperbaiki proyek asli, dan membiarkannya bekerja pada situasi saat ini. Berhenti menerima permintaan dan persyaratan baru dari pemangku kepentingan dan pemilik produk . Kemudian biarkan tim bekerja pada proyek sampai itu menjadi refactored dan siap untuk pergi.

Satu saran yang dapat membantu: Jika Anda memiliki kode yang belum diuji sehingga Anda tidak memiliki waktu yang cukup untuk melakukan refactor dan pengujian ulang dalam dua minggu sprint, pertimbangkan terlebih dahulu membuat beberapa perubahan kecil yang tidak terkait dengan kode tersebut sehingga Anda dapat fokus pada tes menulis untuk sprint pertama atau dua. Mungkin Anda dapat mengidentifikasi beberapa klien yang belum diuji kode yang ingin Anda refactor; pilih satu klien dan buat beberapa perubahan lain dari penggunaan pada bisnis yang akan memaksa Anda untuk menulis tes untuk klien itu. Setelah Anda lebih terbiasa dengan kode, dari bekerja dengan itu, dan Anda memiliki lebih banyak tes, dan Anda mungkin telah menyelesaikan beberapa refactor yang berkontribusi kecil, Anda akan berada dalam posisi yang jauh lebih baik untuk menyelesaikan refactoring dan (sekarang lebih mudah ) menguji keduanya dalam satu iterasi.

Pendekatan lain adalah membuat salinan kode yang menyinggung, memperbaikinya, dan kemudian memindahkan klien satu per satu ke kode baru. Pekerjaan ini dapat dipecah di seluruh iterasi.

Dan jangan menyerah: Jangan hanya menerima bahwa refactoring yang besar tidak dapat dipecah menjadi langkah-langkah yang lebih kecil. Pendekatan termudah / tercepat / terbaik mungkin membutuhkan waktu lebih lama dari iterasi. Tapi itu tidak berarti bahwa tidak ada cara untuk melakukan potongan seukuran iterasi.