Bagaimana cara membenarkan waktu refactoring kode?

Memiliki proyek yang sangat besar, lebih dari 70k LOC.

Proyek pasti membutuhkan beberapa kode refactoring di Core Framework dan di bagian lain juga. Tidak ada waktu yang ditentukan pada awal proyek untuk refactoring. Namun dengan waktu dan lebih dari 40 pengembang bergabung dan meninggalkan proyek. Dari sudut pandang saya sangat diperlukan.

Apa yang akan menjadi poin utama Anda dalam berdebat dan membela prinsip pengembangan perangkat lunak yang tepat?

Ketika mengerjakan aplikasi legacy atau brownfield, Anda tergoda untuk melakukan "pembersihan musim semi" dengan harapan untuk memperbaiki semuanya kembali ke bentuk semula. Itu sama sekali tidak menggunakan sumber daya yang bisa dibenarkan. Lagi pula, bagaimana menghentikan pengembangan pada perangkat lunak yang berfungsi (hanya kode kerja yang dapat di-refactored) yang jusi? Bisakah Anda menjamin waktu yang dihabiskan untuk Fase Besar Refactoring akan melunasi nanti dan tidak menyebabkan kemunduran pada proyek?

bagaimana kamu memakan se ekor gajah? Satu gigitan sekaligus. Setiap kali Anda perlu menerapkan fitur baru atau memperbaiki bug, Anda melihat apakah bagian itu perlu diperbaiki. Seperti yang dikatakan aturan pramuka, "Selalu tinggalkan perkemahan lebih bersih daripada yang Anda temukan." Refactoring seharusnya tidak menjadi fase terpisah, itu adalah bagian dari pengembangan setiap hari.

Ketika Anda mendapatkan budaya kualitas ini diperkenalkan ke tim pengembangan, kualitas akan meningkat. Setelah itu tidak ada apa pun untuk dibenarkan manajemen.

Secara umum, refactoring harus dilakukan untuk memungkinkan perubahan lain yang perlu Anda lakukan pada kode atau sebagai langkah pembersihan alami setelah perubahan dilakukan pada kode. Dalam hal ini, tidak ada yang bisa dibenarkan. Refactoring hanyalah bagian dari proses melakukan pekerjaan pada proyek. Waktu ditagih untuk tugas yang sedang Anda kerjakan ketika Anda melakukan refactoring.

Jika itu tidak dilakukan sedikit demi sedikit, maka itu tidak benar-benar refactoring, eh?

Semua jawaban bagus di sini - tetapi bolehkah saya menambahkan dimensi bisnis untuk ini. Izinkan saya bertanya mengapa MENGAPA? (pikirkan bos rambut runcing Anda)

PHB: mengapa?
Anda: Ini akan membuat segalanya lebih mudah untuk diperbaiki
PHB: Jadi-apa?
Anda: Ini akan meningkatkan throughput - kita akan mendapatkan bangunan baru lebih cepat?
PHB: Jadi-apa?
Anda: Err ... Pelanggan yang lebih bahagia?
PHB: WTF?
Anda: maksud saya peningkatan rekomendasi, kepuasan yang lebih besar, 
     lebih banyak keuntungan lebih cepat karena perputaran yang rendah
PHB: Oh! Terdengar bagus. Tapi itu hanya "terdengar" bagus, bisakah saya melihatnya?
Anda: WTF?
PHB: Tunjukkan saya uang! (yaitu angka tolong)
Anda: Oh! Brb ... (pergi dan letakkan beberapa angka di spreadsheet sederhana untuk menjelaskan kasus Anda)

Pada dasarnya Anda harus membuat kasus bisnis - jalankan beberapa angka untuk mengklarifikasi proses pemikiran Anda dan mendapatkan angka untuk mencerminkan 'manfaat' secara objektif. Anda juga akan tahu berapa banyak waktu yang dibutuhkan, perkiraan biaya, dll. Ini harus masuk akal. Jika itu layak, Anda akan mendapatkan sinyal hijau dan mungkin mempelopori inisiatif juga :)

Jika Anda berpikir bagaimana saya bisa mengukur semuanya, coba buku ini

Refactoring, seperti aktivitas lainnya, harus memiliki tujuan yang jelas. Setelah tujuan itu jelas, Anda akan mempertimbangkan status proyek saat ini dan tahap siklus hidup. Untuk proyek pengembangan yang 80% selesai, 30% di belakang jadwal Anda harus membenarkan upaya refactoring berdasarkan pada tujuan yang ditetapkan sebelumnya. Dalam contoh ini, jika potongan kode diuji unit dan berfungsi baik di lingkungan pengembangan, sulit untuk membenarkan refactoring.

Fakta bahwa 40 pengembang pergi mungkin tidak sedramatis kedengarannya. Saya berharap bahwa para pengembang tersebut telah mengirimkan kode kerja yang ditinjau dan diuji. Jadi, kecuali ada masalah yang diketahui dalam kode ini, saya akan membiarkannya apa adanya. Idenya adalah bahwa dalam proyek besar seperti milik Anda, saya berharap bahwa ada standar dan prosedur dan bahwa kode ini tidak berantakan sama sekali.

Ingatlah bahwa refactoring akan menyebabkan banyak jika tidak semua tes yang telah dilakukan diulang. Juga, karena refactoring dengan ukuran ini tidak dapat dilakukan oleh satu atau dua anggota senior, refactoring dapat menimbulkan masalah yang tidak ada. Ini adalah risiko yang tidak boleh diabaikan.

Karena itu, tidak biasa menambahkan tugas ke proyek ketika hal yang tidak terduga terjadi. Jadi, jika pengembang menghilang karena suatu alasan, bahwa itu akan dianggap sebagai peristiwa yang bersifat khusus dan tindakan apa pun untuk memperbaiki situasi harus diambil. Itu akan diperlakukan seperti api atau gempa bumi, dll.

Singkatnya, saya tidak akan memperbaiki kode kerja besar dalam proyek besar tanpa alasan teknis yang kuat, khususnya bahwa kita semua tahu bahwa sebagian besar proyek biasanya dalam status terlambat.

Bayangkan Anda berada di depan tembok yang panjang dan besar. Anda harus pergi ke sisi lain.

Entah Anda memperbaiki dinding untuk membangun pintu, atau Anda memutarnya.

Perkirakan waktu untuk kedua solusi dan Anda mendapatkan justifikasi Anda untuk refactoring.

Jangan lupa untuk melipatgandakan waktu dalam solusi kedua dengan jumlah orang yang perlu pergi ke sisi lain dinding.

Ketika saya membaca di salah satu jawaban lain, makan gajah ini satu gigitan sekaligus. Saya terlibat dalam mengaudit proyek internasional besar, di mana anggota tim tersebar secara geografis. Setelah membangun dua versi pertama dari perangkat lunak, tim sepakat bahwa pendekatan mereka, gaya pengkodean dan solusi pembangunan tidak konsisten. Mereka sepakat untuk menulis bagian-bagian baru dari aplikasi mengikuti aturan dan konvensi baru dan ketika (dan hanya kemudian) mereka harus mengubah beberapa kode lama, pertama-tama mereka refactor untuk memenuhi konvensi baru. Semuanya bekerja dengan baik. Proses refactoring hampir di bulan ke-5, beberapa kode dire-refored, beberapa masih belum. Fitur baru dibawa dalam waktu, klien senang, devs senang, tim QA juga senang. Situasi menang-menang :)

Poin utama dari refactoring adalah membuat segalanya lebih mudah di masa depan. Anda tidak dapat menunjukkan keuntungan dari refactoring kecuali jika Anda membandingkan beberapa proyek jangka panjang yang dilakukan dengan sedikit dan sedikit tanpa refactoring yang konstan. Secara umum diterima lintas pengembang, bahwa refactoring mengurangi biaya pemeliharaan dan implementasi perubahan, tetapi hal itu sulit dibuktikan dari sudut pandang bisnis. Alasan utama untuk menerapkan refactoring adalah untuk mengurangi Utang Teknis .

Juga, refactoring harus merupakan proses yang berkelanjutan dan waktu yang dihabiskan untuk refactoring harus dimasukkan dalam tugas pengembangan itu sendiri. Memiliki "tugas refactoring" khusus bukanlah ide yang baik.