Kapan harus berhenti dan kapan harus menghapus di Jawa

Sebagai bagian dari upaya refactoring atau hanya pengembangan yang sedang berlangsung, metode tertentu atau mungkin seluruh kelas mungkin menjadi usang dalam beberapa hal. Java mendukung @Deprecatedanotasi untuk menunjukkan bahwa mungkin ada cara yang lebih baik untuk menangani fungsi yang dimaksud. Saya membayangkan ini sangat berguna di API publik di mana efek menghapus bagian dari API mungkin tidak diketahui. Untuk API non-publik dan proyek yang menggunakan sistem kontrol revisi (jadi menghapus bisa dibatalkan dalam beberapa hal), kapan lebih tepat untuk mencela daripada menghapus elemen yang sudah usang?

Apakah API Anda adalah API yang menghadap publik? Itu menentukan apakah Anda harus mencabut atau menghapus. Jika API hanya untuk keuntungan Anda (yaitu hanya digunakan dalam perusahaan Anda), maka yang terbaik adalah menghapus kode yang menyinggung. Ini jauh lebih bersih dan akan menyebabkan lebih sedikit sakit kepala perawatan dalam jangka panjang.

Namun, jika API terbuka untuk umum, hanya dengan menghapus suatu metode dapat menyebabkan kode yang digunakan untuk bekerja dengan versi pustaka Anda yang lama berhenti berfungsi. Di situlah segalanya menjadi berantakan. Berikut ini adalah beberapa pedoman:

• API internal: hapus dan bukannya usang. Jika ada klien yang menggunakan kelas atau metode internal, itu adalah kesalahan mereka jika alat rusak.
• API Eksternal: deprecate first, hapus nanti. Penghentian adalah bendera bahwa sesuatu akan dihapus nanti. Nanti tergantung apa yang menurut Anda masuk akal. Paling tidak berikan 2-3 versi sebelum benar-benar menghapus kode usang.

Mungkin merupakan ide bagus untuk mengatur pengingat saat Anda @membalas ulang kelas atau metode. Anda melakukannya untuk mempromosikan keusangannya. Jadi, tebak berapa lama waktu yang dibutuhkan, sebagai waktu luang, sesuai keinginan, untuk menghilangkan semua referensi. Tandai sebagai @deprecated dan letakkan pengingat di kalender Anda. Saat Anda mendapatkan pengingat, periksa. Jika tidak lagi digunakan, hapus. Jika beberapa referensi tetap yang dapat dengan cepat diperbarui, lakukan itu dan hapus item. Jika masih ada pekerjaan yang lebih signifikan, tundukkan pengingat Anda sedikit ke depan.

Lakukan ini cukup kali dan Anda akan merasakan berapa lama waktu yang dibutuhkan untuk menyingkirkan kelas atau metode dalam proyek Anda.

IMHO jika Anda dapat memastikan bahwa tidak ada yang menggunakannya dan tidak akan pernah, hapus saja. (Ini bisa rumit di hadapan refleksi, atau komponen eksternal seperti makro Velocity - IDE modern seperti IntelliJ dapat menemukan referensi di misalnya JSP tetapi tidak melalui refleksi atau dalam Velocity.)

Jika ada alternatif yang lebih baik tetapi yang lama masih digunakan di banyak tempat, dan saat ini Anda tidak punya waktu untuk memperbaiki semua kode klien, cukup memadai untuk @membahas kelas / metode yang sudah usang (dengan komentar yang memadai tentang alternatif yang disukai).