Pertimbangkan ini. Ketika Anda "menemukan hal-hal yang mengganggu (...) untuk dibersihkan" dan Anda membuat keputusan eksekutif untuk melakukannya, Anda memotong sisa tim Anda dari diskusi prioritas dan keputusan. Anda membiarkan Anda truf orang agenda lain karena hubungan istimewa dengan kode. Saya pikir itu tidak baik. Dari pengalaman, itu juga mengarah pada kebencian tim / pemegang saham.
Sebaliknya, buat masalah / tugas untuk pembersihan / refactoring. Sementara itu segar di pikiran Anda, buatlah daftar alasannya penting: perkiraan peningkatan stabilitas, kemudahan perawatan, hal-hal semacam itu. Mungkin termasuk estimasi usaha tergantung pada bagaimana tim Anda bekerja. Kemudian dalam rapat pemilihan / penugasan / prioritas tugas Anda berikutnya, sampaikan tugas refactoring Anda dan posisikan itu terhadap tugas-tugas lain. Sebagai tim, putuskan kapan harus diselesaikan.
Tolong jangan berpikir aku menyuruhmu membuang akal sehat atas nama prinsip. Gunakan kepalamu. Jika ada sesuatu yang jelek dalam fungsi yang Anda edit, itu bukan tugas refactoring baru. Perbaiki dan periksa semuanya. Jika mengganti nama properti yang Anda kerjakan menjadi sesuatu yang lebih masuk akal memengaruhi beberapa file sumber tambahan, itu bukan tugas refactoring baru. Perbaiki dan periksa semuanya. Jika, di sisi lain, Anda tidak suka cara pengembang lain (Mitch, saya benci pria itu) melakukan sesuatu dalam fungsi yang tidak Anda edit dan mengatakan fungsi tampaknya berfungsi dengan baik, biarkan saja untuk saat ini. Buat tugas refactoring dan sajikan kasing Anda ke tim Anda.
Jika refactoring selalu dipilih oleh tim Anda demi fitur baru, mulailah mencari pekerjaan lain. Lebih mudah untuk menemukan pekerjaan ketika Anda sudah memilikinya.