Hampir semua hal dapat dianalisis dalam hal biaya dan manfaat, dan saya pikir ini berlaku di sini.
Manfaat yang jelas dari opsi pertama adalah meminimalkan pekerjaan dalam jangka pendek, dan meminimalkan peluang melanggar sesuatu dengan menulis ulang kode kerja. Biaya yang jelas adalah memperkenalkan inkonsistensi ke dalam basis kode. Ketika Anda melakukan beberapa operasi X, itu dilakukan dengan satu cara di beberapa bagian kode, dan cara yang berbeda di bagian kode yang berbeda.
Untuk pendekatan kedua, Anda sudah mencatat manfaat yang jelas: konsistensi. Biaya yang jelas adalah bahwa Anda harus membengkokkan pikiran Anda untuk bekerja dengan cara yang mungkin telah Anda tinggalkan bertahun-tahun yang lalu, dan kode tetap konsisten tidak terbaca.
Untuk pendekatan ketiga, biaya yang jelas adalah harus melakukan lebih banyak pekerjaan. Biaya yang tidak terlalu jelas adalah Anda dapat merusak barang-barang yang berfungsi. Ini sangat mungkin terjadi jika (seperti yang sering terjadi) kode lama memiliki tes yang tidak memadai untuk memastikan bahwa kode itu terus berfungsi dengan benar. Manfaat yang jelas adalah bahwa (dengan asumsi Anda berhasil melakukannya) Anda memiliki kode baru yang bagus dan berkilau. Seiring dengan menggunakan konstruksi bahasa baru, Anda memiliki kesempatan untuk memperbaiki basis kode, yang hampir selalu akan memberikan perbaikan dalam dirinya sendiri, bahkan jika Anda masih menggunakan bahasa persis seperti yang ada ketika ditulis - tambahkan konstruksi baru yang membuat pekerjaan lebih mudah, dan itu mungkin merupakan kemenangan besar.
Satu poin utama lainnya: saat ini, tampaknya modul ini telah memiliki perawatan minimal untuk waktu yang lama (meskipun proyek secara keseluruhan sedang dipertahankan). Itu cenderung menunjukkan bahwa itu ditulis dengan cukup baik dan relatif bebas bug - jika tidak, itu mungkin akan mengalami lebih banyak pemeliharaan sementara.
Itu mengarah ke pertanyaan lain: apa sumber perubahan yang Anda buat sekarang? Jika Anda memperbaiki bug kecil di modul yang secara keseluruhan masih memenuhi persyaratannya dengan baik, itu akan cenderung menunjukkan bahwa waktu dan upaya refactoring seluruh modul kemungkinan besar akan sia-sia - pada saat seseorang perlu mengacaukan sekali lagi, mereka mungkin berada di posisi yang kira-kira sama dengan Anda sekarang, mempertahankan kode yang tidak memenuhi harapan "modern".
Namun, ada kemungkinan bahwa persyaratan telah berubah, dan Anda sedang mengerjakan kode untuk memenuhi persyaratan baru itu. Dalam hal ini, kemungkinan besar bahwa upaya pertama Anda tidak akan benar-benar memenuhi persyaratan saat ini. Ada juga peluang yang jauh lebih besar bahwa persyaratan akan menjalani beberapa putaran revisi sebelum mereka stabil kembali. Itu berarti Anda jauh lebih mungkin melakukan pekerjaan signifikan dalam modul ini dalam waktu yang relatif dekat, dan jauh lebih mungkin untuk melakukan perubahan di seluruh modul, tidak hanya di satu area yang Anda ketahui tentang benar. sekarang. Dalam hal ini, refactoring seluruh modul jauh lebih mungkin untuk memiliki manfaat nyata, jangka pendek yang membenarkan pekerjaan tambahan.
Jika persyaratan telah berubah, Anda mungkin juga perlu melihat jenis perubahan apa yang terlibat, dan apa yang mendorong perubahan itu. Misalnya, mari kita asumsikan Anda memodifikasi Git untuk mengganti penggunaan SHA-1 dengan SHA-256. Ini adalah perubahan dalam persyaratan, tetapi ruang lingkupnya jelas dan sempit. Setelah Anda membuatnya menyimpan dan menggunakan SHA-256 dengan benar, Anda tidak akan menemukan perubahan lain yang memengaruhi sisa basis kode.
Di arah lain, bahkan ketika itu mulai kecil dan terpisah, perubahan ke antarmuka pengguna memiliki kecenderungan untuk menggelembung, jadi apa yang dimulai sebagai "tambahkan satu kotak centang baru ke layar ini" berakhir lebih seperti: "ubah UI tetap ini untuk mendukung templat yang ditentukan pengguna, bidang khusus, skema warna yang disesuaikan, dll. "
Untuk contoh sebelumnya, mungkin paling masuk akal untuk meminimalkan perubahan dan kesalahan di sisi konsistensi. Untuk yang terakhir, refactoring lengkap jauh lebih mungkin untuk membayar.