Saya sangat percaya pada Aturan Pramuka :
Selalu periksa modul dalam pembersih daripada ketika Anda memeriksanya. "Tidak peduli siapa penulis aslinya, bagaimana jika kita selalu berusaha, tidak peduli seberapa kecil, untuk meningkatkan modul. Apa hasilnya? Saya pikir jika kita semua mengikuti aturan sederhana itu, kita akan melihat akhir dari kemunduran tanpa henti dari sistem perangkat lunak kita, sebagai gantinya, sistem kita akan secara bertahap menjadi lebih baik dan lebih baik ketika mereka berevolusi. daripada hanya individu yang merawat bagian kecil mereka sendiri.
Saya juga sangat percaya pada ide terkait Refactoring Opportunistik :
Meskipun ada tempat untuk beberapa upaya refactoring terjadwal, saya lebih memilih untuk mendorong refactoring sebagai kegiatan oportunistik, dilakukan kapan saja dan di mana pun kode perlu dibersihkan - oleh siapa pun. Artinya adalah bahwa setiap saat seseorang melihat beberapa kode yang tidak sejelas seharusnya, mereka harus mengambil kesempatan untuk memperbaikinya di sana dan kemudian - atau setidaknya dalam beberapa menit.
Khususnya perhatikan kutipan berikut dari artikel refactoring:
Saya waspada terhadap praktik pengembangan yang menyebabkan gesekan untuk refactoring oportunistik ... Perasaan saya adalah bahwa sebagian besar tim tidak melakukan cukup refactoring, jadi penting untuk memperhatikan apa pun yang menghambat orang untuk melakukannya. Untuk membantu menghilangkan ini, perhatikan kapan saja Anda merasa kecil hati untuk melakukan refactoring kecil, yang Anda yakin hanya akan memakan waktu satu atau dua menit. Setiap penghalang seperti itu adalah bau yang harus memicu percakapan. Jadi buatlah catatan tentang keputusasaan dan bawa bersama tim. Paling tidak itu harus dibahas selama retrospektif Anda berikutnya.
Tempat saya bekerja, ada satu praktek pembangunan yang menyebabkan berat gesekan - Kode Ulasan (CR). Setiap kali saya mengubah apa pun yang tidak dalam lingkup "tugas" saya, saya ditegur oleh pengulas saya bahwa saya membuat perubahan lebih sulit untuk ditinjau. Ini terutama benar ketika refactoring terlibat, karena itu membuat perbandingan diff "baris demi baris" menjadi sulit. Pendekatan ini adalah standar di sini, yang berarti refactoring oportunistik jarang dilakukan, dan hanya refactoring "terencana" (yang biasanya terlalu sedikit, terlalu terlambat) terjadi, jika sama sekali.
Saya mengklaim bahwa manfaatnya sepadan, dan bahwa 3 pengulas akan bekerja sedikit lebih keras (untuk benar-benar memahami kode sebelum dan sesudah, daripada melihat pada ruang lingkup sempit di mana garis berubah - ulasan itu sendiri akan lebih baik karena itu saja ) sehingga 100 pengembang berikutnya yang membaca dan memelihara kode akan mendapat manfaat. Ketika saya mempresentasikan argumen ini, pengulas saya, mereka mengatakan mereka tidak memiliki masalah dengan refactoring saya, asalkan tidak dalam CR yang sama. Namun saya mengklaim ini adalah mitos:
(1) Sebagian besar waktu Anda hanya menyadari apa dan bagaimana Anda ingin refactor ketika Anda berada di tengah-tengah tugas Anda. Seperti Martin Fowler katakan:
Ketika Anda menambahkan fungsionalitas, Anda menyadari bahwa beberapa kode yang Anda tambahkan berisi beberapa duplikasi dengan beberapa kode yang ada, jadi Anda perlu refactor kode yang ada untuk membersihkan sesuatu ... Anda mungkin mendapatkan sesuatu yang berfungsi, tetapi menyadari bahwa itu akan menjadi lebih baik jika interaksi dengan kelas yang ada diubah. Ambil kesempatan itu untuk melakukan itu sebelum Anda menganggap diri Anda sudah selesai.
(2) Tidak ada yang akan memandang positif Anda melepaskan "refactoring" CR yang seharusnya tidak Anda lakukan. CR memiliki overhead tertentu dan manajer Anda tidak ingin Anda "membuang waktu" untuk refactoring. Ketika dibundel dengan perubahan yang seharusnya Anda lakukan, masalah ini diminimalkan.
Masalah ini diperburuk oleh Resharper, karena setiap file baru yang saya tambahkan ke perubahan (dan saya tidak bisa tahu sebelumnya file mana yang akhirnya akan berubah) biasanya dipenuhi dengan kesalahan dan saran - sebagian besar tepat dan benar-benar layak pemasangan.
Hasil akhirnya adalah saya melihat kode yang mengerikan, dan saya membiarkannya di sana. Ironisnya, saya merasa bahwa memperbaiki kode seperti itu tidak hanya tidak akan memperbaiki posisi saya, tetapi sebenarnya menurunkannya dan melukis saya sebagai orang yang "tidak fokus" yang membuang waktu memperbaiki hal-hal yang tidak dipedulikan orang lain daripada melakukan pekerjaannya. Saya merasa tidak enak karena saya benar-benar membenci kode buruk dan tidak tahan melihatnya, apalagi menyebutnya dari metode saya!
Adakah pemikiran tentang bagaimana saya dapat memperbaiki situasi ini?
your manager doesn't want you to "waste your time" on refactoring