Berapa lama menunggu sebelum menghapus metode yang sudah usang? [Tutup]

38

Saya memelihara API publik dan harus mencabut metode.

Apakah ada aturan umum tentang berapa bulan / tahun / versi sebelum penghapusan saya harus mencabut metode?

java deprecation

— deviDave
sumber

27

Aturan umum adalah "tetap di sana selama Anda dan / atau pelanggan Anda membutuhkannya."

— Robert Harvey

15

Tentukan "publik". Perangkat lunak bebas dan sumber terbuka, dengan penafian "gunakan dengan risiko Anda sendiri" yang biasa? Atau perangkat lunak yang dijual di mana ada kontrak?

— Doc Brown

11

Ini sangat tergantung pada pasar di mana pengguna Anda berada dan apakah mereka membayar Anda untuk API atau tidak.

— 17 dari 26

10

Itu juga tergantung pada mengapa Anda "harus" mengurangi nilai itu; Apakah cara lama risiko keamanan? Apakah Anda baru saja menemukan alasan mengapa cara lama secara fundamental dan tidak stabil tidak stabil karena keputusan desain yang tidak menguntungkan? Apakah cara lama jauh lebih lambat sekarang daripada dulu? Apakah Anda kehabisan memori pada sistem target Anda (misalnya, sistem tertanam) dan Anda benar-benar tidak dapat memuat kedua API di atasnya? Atau apakah Anda baru saja menemukan cara "lebih baik" dan Anda hanya ingin membersihkan kode lama untuk mengurangi overhead pemeliharaan Anda?

— jrh

8

java.io.StringBufferInputStreamditinggalkan sejak JDK 1.1 (1997?). Tidak ada jawaban yang baik atau salah untuk pertanyaan ini. Itu tergantung pada kebutuhan Anda untuk memberikan kompatibilitas ke belakang.

— Laiv

52

Minimal, Anda harus menyimpan metode yang sudah usang dalam satu versi sebelum menghapusnya yang tampak agak jelas ketika saya menuliskannya. Saya tidak berpikir ada waktu maksimum tetapi jika Anda tidak pernah benar-benar menghapusnya, penghinaan menjadi sedikit sia-sia.

Rilis versi besar adalah waktu yang tepat untuk menghapus metode yang sudah usang. Rilis minor biasanya tidak mengandung perubahan yang melanggar. Seperti yang dicatat cHao dalam komentar, penghentian tidak selalu menyiratkan bahwa akan ada penghapusan akhirnya jadi jika Anda berencana untuk menghapus sesuatu setelah penghentian, Anda harus secara eksplisit mencatatnya dan memberikan beberapa panduan pada timeline.

— JimmyJames
sumber

58

Penghentian tidak selalu tentang penghapusan akhirnya, jadi penghentian tanpa penghapusan tidak ada gunanya (dan seringkali hal yang benar jika kompatibilitas ke belakang penting). Seringkali intinya tidak lebih dari "kita memiliki cara yang lebih baik sekarang, jadi Anda tidak harus melakukannya dengan cara ini lagi"

— cHao

9

@ cHao Jika ada sesuatu yang sudah ketinggalan zaman, Anda seharusnya tidak mengharapkannya untuk terus ada di sana. Saya kira jika Anda ingin membuat pernyataan khusus dalam proyek Anda yang menyatakan bahwa Anda tidak akan menghapus fungsionalitas yang sudah usang, itu baik-baik saja tetapi sebaliknya, ya itu tersirat bahwa akan ada penghapusan akhirnya. Maksud saya adalah bahwa jika Anda tidak mempertahankan semacam kekakuan di sekitar ini, orang mungkin akan percaya bahwa itu tidak akan pernah terjadi. Ini telah muncul dengan versi Java terbaru di mana fungsionalitas yang telah ditinggalkan selama satu dekade atau lebih sekarang sedang dihapus.

— JimmyJames

6

@ cHao Saya lebih suka proyek menghapus fungsinya yang sudah usang. Tidak hanya ada manfaat dari pengguna yang termotivasi untuk beralih, tetapi juga mencegah antarmuka yang tidak terpakai mengganggu peningkatan lainnya.

— jpmc26

9

@ cHao Ini adalah hal yang sensitif terhadap konteks. Dalam pengalaman saya, kebijakan penghinaan jelas. Dinyatakan dengan jelas bahwa fungsi yang usang akan dihapus di beberapa titik di masa mendatang. Seringkali fungsi yang usang memiliki masalah yang membuatnya bermasalah untuk digunakan dan itu bukan hanya masalah apakah Anda menghargai kompatibilitas atau tidak.

— JimmyJames

6

Saya akan berpadu untuk setuju dengan @JimmyJames bahwa penghentian jelas menyiratkan penghapusan yang akan datang. Periode penghentian ada sebagai cara untuk menyediakan kompatibilitas mundur sementara sehingga konsumen dapat bermigrasi ke fungsi yang lebih baru. Seharusnya sama sekali tidak ada harapan bahwa fungsionalitas yang sudah usang akan tetap tak terbatas. Jika fungsi lama akan tetap ada, tidak ada alasan untuk mencabutnya.

— Eric King

17

Ini semata-mata tergantung pada jaminan stabilitas seperti apa yang Anda berikan kepada pengguna Anda, dan berapa banyak rasa sakit yang ingin Anda sebabkan bagi pengguna Anda.

Idealnya, API Anda menggunakan semver sehingga setiap perubahan yang melanggar menyebabkan nomor versi utama bertambah. Dalam praktiknya, diinginkan untuk melakukan ini hampir tidak pernah. Jika API Anda diinstal melalui beberapa manajer paket, Anda mungkin ingin membuat nama paket baru setelah perubahan yang melanggar sehingga peningkatan sederhana tidak menyebabkan konflik (misalnya myapi2 v2.123.4vs myapi3 v3.2.1). Itu mungkin tidak perlu jika manajer paket Anda mendukung dependensi versi yang lebih ketat (mis. Spesifikasi dependensi seperti ~v2.120itu tidak termasuk v3.*), tetapi nama paket yang berbeda memiliki keuntungan bahwa versi yang tidak kompatibel dapat digunakan berdampingan dengan sangat mudah. Bahkan ketika menggunakan semver, masuk akal untuk memiliki periode penghentian.

Semver tidak selalu berlaku. Maka lebih penting untuk mengomunikasikan kebijakan stabilitas yang jelas. Sebagai contoh:

Fitur eksperimental dapat dihapus tanpa pemberitahuan.
Fitur dapat dihapus karena alasan keamanan kapan saja.
Fitur lain hanya akan dihapus
- ... setelah tidak digunakan lagi dalam versi yang dirilis
- ... di mana versi itu setidaknya berusia tiga bulan
- ... dan akan ditandai dengan tonjolan di versi utama.

Kebijakan seperti itu bekerja sangat baik ketika Anda memiliki rilis reguler sehingga ada periode penghentian yang jelas, misalnya satu tahun.

Selain menandai bagian mana pun dari API yang sudah usang, Anda harus membuat penghentian tersebut diketahui secara luas. Sebagai contoh:

Miliki bagian di changelog Anda tentang arah dan penghentian di masa mendatang.
Siarkan niat Anda untuk berhenti sebelum melakukan penghentian, dan dengarkan komunitas untuk melihat apakah ada keberatan yang substansial.
Komunikasikan manfaat apa yang akan datang dari perubahan ini. Tergantung pada basis pengguna Anda, buletin, presentasi, posting blog, atau siaran pers mungkin merupakan media yang sesuai. Memiliki putaran “kami menciptakan fitur baru yang luar biasa! (yang mengharuskan fitur lama yang banyak digunakan ini untuk dihapus) ”sedikit lebih membuat frustrasi daripada menghapus fitur tanpa konteks.

Adapun periode penghentian tepat untuk memilih, pertama-tama lihat apakah Anda harus menghormati kontrak dukungan dengan pengguna Anda. Kontrak semacam itu mungkin mengharuskan Anda untuk mempertahankan kompatibilitas untuk beberapa periode. Jika tidak, pertimbangkan dampak hilir apa pun. Cobalah untuk berubah lebih cepat daripada pengguna hilir sehingga mereka dapat melalui siklus penghentian mereka sendiri. Pengguna hilir akan membutuhkan waktu untuk beradaptasi dengan perubahan Anda, jadi Anda seharusnya tidak pernah memiliki periode penghentian yang lebih pendek dari sebulan.

— amon
sumber

3

Diturunkan karena ini:

Ideally, your API uses semver so that any breaking change causes the major version number to be incremented. In practice, it is desirable to do this almost never.

Apa gunanya menggunakan semver untuk mengindikasikan perubahan yang pecah jika Anda mengikutinya dengan mengatakan Anda tidak boleh memperkenalkan versi utama baru?

— mrsmn

6

Apakah benar-benar ide yang baik untuk mengganti nama paket jika ada perubahan besar? Untuk itulah nomor versi diperuntukkan. Aku benci ketika mereka juga mengganti nama mereka, itu benar-benar mengacaukan manajemen ketergantungan Maven.

— AJPerez

@ AJPerez Saya mengerti itu tidak ideal, tetapi dapat mencegah konflik dalam grafik ketergantungan besar dengan dependensi transitif: Saya bergantung pada libfoo yang bergantung pada libconflict v1.2.3, dan saya juga bergantung pada libbar yang bergantung pada libconflict v2.3.4. Kemudian, saya tidak dapat memilih versi libconflict yang memenuhi semua dependensi - kecuali libconflict dan libconflict2 adalah paket yang berbeda. Khusus untuk Java, penggantian nama seperti itu mengganggu b / c. Saya harus mengubah semua impor. Untungnya, Java 9 (modul) mendukung penggunaan versi yang saling bertentangan.

— amon

1

@ mrsmn Memecah perubahan itu mengganggu namun Anda mengemas atau menamainya. Semver hanya membahas sebagian kecil dari masalah ini: bisa mengetahui apakah pemutakhiran akan merusak apa pun. Tetapi begitu Anda memiliki perubahan yang berarti, Anda masih harus mengeluarkan upaya untuk mengakomodasi perubahan ini. Oleh karena itu, lebih baik jika API berusaha sangat keras untuk menjadi stabil mungkin. Idealnya mereka dirancang sedemikian rupa sehingga dapat diperpanjang tanpa merusak kompatibilitas.

— amon

@ AJPerez ya. Ya itu bagus. Orang-orang mengacaukan versi sepanjang waktu. Perbaikan bug (mungkin xxx ++) sering rusak (diperkirakan x ++. Xx). Seperti yang ditunjukkan amon Anda (dan maksud saya Anda sebagai pengguna ketergantungan) memiliki masalah yang harus Anda perbaiki. Saya tahu kode saya berfungsi dengan foo 3.2.1, mungkin berfungsi dengan foo 3.3.0. Saya tahu kode saya berfungsi dengan foo, mungkin berfungsi dengan foo-2. Saya menggunakan semver karena popularitas dan itu tidak menyakitkan, tetapi sebenarnya tidak jelas bagi saya bahwa itu membeli Anda terlalu banyak.

— Jared Smith

14

Idealnya, Anda ingin menunggu sampai tidak ada yang menggunakan metode yang sudah tidak digunakan lagi. Mengingat Anda menggunakan API publik, itu mudah dilacak, tetapi Anda mungkin menunggu lama sekali.

pada 2015, Google memiliki masalah serupa dengan stlport API di OS Android mereka. Mereka telah mencabutnya dan ingin menghapusnya, tetapi banyak aplikasi masih menggunakannya. Mereka menemukan solusi cerdas:

Pada dasarnya, mereka menambahkan sleep 8 detik () selama boot dari aplikasi apa pun yang masih menggunakan API dengan pesan log yang sesuai untuk para pengembang. Sebulan kemudian, mereka menggandakannya menjadi 16 detik. lalu sebulan kemudian, mereka dapat dengan aman menghapus antarmuka API karena tidak ada yang tersisa menggunakannya.

Ini bisa menjadi cara yang sangat efektif untuk melakukan ini. Satu-satunya masalah sebenarnya adalah jika API Anda sudah sangat tua dan telah secara aktif menggunakan konsumen yang tidak lagi didukung secara aktif. Sayangnya, Anda mungkin tidak akan dapat memperbaiki sendiri konsumen seperti itu, tetapi pada saat itu Anda tidak dapat melakukan lebih dari sekadar menghapus metode dan menghancurkan konsumen.

— Nzall
sumber

5

Imut. Sangat imut.

— David Hammen

8

Waktu minimum untuk menyediakan metode yang tidak digunakan lagi tergantung pada siklus pengembangan program menggunakan API Anda. Sebagai angka rata-rata, 1 tahun seharusnya cukup.

Adapun waktu maksimum sebelum Anda harus menghapus metode usang, saya berpendapat bahwa tidak ada hal seperti itu. Tidak peduli berapa lama Anda menunggu, menghapus metode yang sudah usang akan selalu merusak sesuatu. Beberapa program menggunakan API Anda yang sudah usang tidak dipelihara secara aktif, dan melanggar kompatibilitas akan berarti akhir dari program tersebut.

Saya sarankan Anda menghapus metode yang sudah usang saat Anda mendapatkan sesuatu dari penghapusan :

bug terdeteksi yang memengaruhi metode usang secara khusus
Anda akan memperbaiki kode dan mempertahankan metode yang sudah usang akan membutuhkan upaya yang signifikan
Anda mengoptimalkan struktur internal perpustakaan Anda, dan metode yang sudah usang tidak cocok lagi.

Menghapus metode yang sudah usang hanya karena sudah tidak digunakan lagi selama X bulan / tahun atau karena Anda merilis versi baru berarti merusak kompatibilitas secara sewenang-wenang tanpa alasan yang jelas.

— Dmitry Grigoryev
sumber

7

Pertama, Anda harus mempertimbangkan apakah Anda ingin usang atau usang.

Sudah usang harus digunakan untuk metode yang dalam beberapa cara berbahaya: keamanan, kinerja, hasil yang salah. Anda ingin menyingkirkan mereka secara relatif cepat, tidak lebih dari 2 versi utama dan pergi ke 3. Untuk masalah yang cukup signifikan, usang dapat dihapus di versi minor berikutnya.

Usang adalah untuk hal-hal yang kurang berguna untuk beberapa alasan, misalnya mengembalikan informasi lebih sedikit atau tidak berfungsi dengan baik, tidak memasukkan banyak opsi dan sebagainya. Ini bisa berkeliaran tanpa batas waktu, tetapi setidaknya harus hadir dalam versi utama berikutnya.

— jmoreno
sumber

Saya akan mengatakan metode yang memberikan hasil yang salah atau merusak keamanan harus segera dinonaktifkan, atau diperbaiki. Metode dengan kinerja buruk dapat bertahan tanpa batas, asalkan kinerjanya dapat diterima oleh sebagian pengguna.

— Dmitry Grigoryev

@DmitryGrigoryev: versi minor tunggal cukup dekat dengan segera.

— jmoreno

4

Jawabannya tergantung pada jenis layanan apa yang Anda berikan kepada pelanggan Anda.

Di salah satu ujung ekstrim, ada kesalahan di Windows.h dari era Win 3.1 yang disebarkan selama dua dekade karena Microsoft sangat percaya pada kompatibilitas ke belakang.

Di ujung lain spektrum, banyak aplikasi web menghapus fitur tanpa memberikan peringatan penghentian.

Berapa banyak klien Anda membayar untuk perangkat lunak Anda sering penting, seperti halnya pekerjaan mereka. Ilmuwan riset biasanya lebih bersedia menerima penghinaan sebagai bagian dari perjalanan kemajuan daripada, katakanlah, bankir atau FAA.

Saya bekerja di perusahaan yang mengembangkan perangkat lunak untuk penggunaan internal. Saya mendukung banyak kelompok selama bertahun-tahun. Satu kelompok memiliki mentalitas "tidak pernah menghapus fitur apa pun". Mereka membutuhkan kemampuan untuk kembali ke file 5-10 tahun yang lalu dan melakukan analisis pada mereka pada rentang waktu terlalu cepat untuk membuat pengembang memasukkan fitur kembali. Sikap satu kelompok adalah "memastikan semua penghinaan ada di catatan tempel, jadi kami dapat menemukannya nanti. " Di tengah, kami memiliki satu grup yang aturannya adalah "Fitur harus dihentikan untuk setidaknya 1 versi dengan peringatan tercetak jika digunakan sebelum menghapusnya." Kelompok itu memiliki ruang uji yang mencakup fitur yang mereka butuhkan. Setiap kali kami merilis versi baru, mereka dengan cepat menjalankan test suite mereka untuk melihat apakah ada penghinaan yang membuat mereka kesulitan.

— Cort Ammon
sumber

4

Saya memelihara API publik dan harus mencabut metode.

Mengapa Anda perlu melakukan ini? Apakah karena ada cara baru yang mengkilap untuk melakukan sesuatu, sehingga metode lama sekarang tidak disarankan, tetapi masih berfungsi dengan baik? Atau apakah metode lama benar-benar perlu pergi karena hal-hal telah berubah secara mendasar?

Jika metode lama tidak menyebabkan masalah aktual, dan dapat bertahan, maka mungkin juga. Jika tidak rusak, jangan memperbaikinya. Apakah Anda benar-benar perlu menghapusnya? Mungkin tandai sebagai usang, dan sertakan catatan dalam dokumentasi bahwa metode lain mungkin lebih efisien, atau apa pun, tetapi mungkin baik-baik saja untuk membiarkannya di tempat.
Jika metode lama benar-benar perlu dilakukan, karena itu menyebabkan Anda sakit kepala karena pemeliharaan, atau karena itu tidak lagi masuk akal karena perubahan lain, maka pantau penggunaannya dan komunikasikan penghinaan tersebut dengan jelas kepada klien. Beri mereka tanggal yang jelas dan setelah itu metode tersebut akan dihapus. (Idealnya, jangan benar-benar menghapusnya segera pada tanggal ini: tunggu sampai tidak ada yang masih menggunakannya sebelum benar-benar menghapusnya. Mungkin perlu pergi lebih cepat, jika itu benar-benar menyebabkan masalah, tetapi setidaknya menunggu penggunaan untuk menjatuhkan sedikit.)
Jika metode lama menyebabkan masalah keamanan, Anda mungkin perlu bergerak lebih cepat dari itu, bahkan mungkin menghapusnya tanpa peringatan, tetapi Anda harus mendokumentasikan perubahan ini di suatu tempat yang sangat terlihat, dan juga mengembalikan pesan yang masuk akal kepada klien yang berusaha menggunakan metode lama.

(Dua poin peluru kedua tercakup dalam jawaban lain, tapi saya pikir yang pertama adalah baru.)

— Trigonometri
sumber

1

Untuk proyek publik, hapus saja jika dan hanya jika Anda perlu.

Ketika Anda melakukan penghapusan API yang tidak perlu, Anda harus mengeluarkan biaya untuk perusahaan dan kontraktor sedemikian rupa sehingga Anda bahkan tidak bisa menghitung karena churn yang mahal.

Ingin perusahaan dan pemrogram independen berhenti menggunakan proyek Anda? Hancurkan barang-barang mereka cukup saat Anda tidak penting dan Anda akan berada di kapal itu dalam waktu singkat.

deprecation != eventual_removal. Jika API berbahaya, Anda menghapusnya. Jika sudah tua, tinggalkan dan dokumentasikan penggantinya.

— kayleeFrye_onDeck
sumber