Blog Metlivi

Cara Memeriksa Apakah API yang Tidak Digunakan Lagi (Deprecated) dalam Artikel Teknis Masih Berfungsi

Ketika sebuah artikel teknis mengutip API yang deprecated, lacak simbol pastinya melalui dokumentasi berversi proyek, catatan rilis, dan instruksi migrasi. "Deprecated" berarti pengelola telah menandai suatu API untuk diganti atau dihapus di masa mendatang; ini tidak berarti API tersebut sudah hilang. Konfirmasikan versi tempat peringatan tersebut muncul, lalu periksa catatan rilis setelahnya untuk penghapusan dan pengganti yang terdokumentasi. `django.conf.urls.url()` pada Django memberikan contoh yang jelas: Django 3.1 menghentikan penggunaannya demi `django.urls.re_path()`, dan Django 4.0 menghapusnya.

29 September 20265 min readEstetika sehari-hari dan ekspresi diriOleh Metlivi Editorial Team
Bagian 1

Mulai dengan API dan versi yang tepat

Catat pustaka, jalur impor lengkap atau nama metode, serta versi yang ditargetkan oleh artikel tersebut. Sebuah nama saja mungkin ambigu: paket dapat mengekspos API dengan nama yang serupa, dan sebuah artikel mungkin merujuk ke versi lama bahkan saat dokumen saat ini menjelaskan versi yang lebih baru. Periksa impor sampel kode dan konteks di sekitarnya untuk mengidentifikasi simbol yang sebenarnya.

Selanjutnya, temukan dokumentasi resmi untuk versi yang dinyatakan dalam artikel. Cari label status seperti “deprecated,” “removed,” atau “backwards incompatible.” Kemudian bandingkan dengan dokumentasi untuk versi yang akan digunakan pembaca. Halaman dokumentasi saat ini mungkin menghilangkan API lama sepenuhnya, sehingga ketiadaannya di sana adalah petunjuk untuk diselidiki, bukan bukti kapan atau mengapa API tersebut hilang.

Bagian 2

Gunakan catatan rilis untuk menyusun linimasa

Catatan rilis menghubungkan sebuah perubahan dengan rilis tertentu. Dalam [catatan rilis Django 3.1](https://docs.djangoproject.com/en/3.1/releases/3.1/), pengelola mencantumkan `django.conf.urls.url()` sebagai deprecated dan mengidentifikasi `django.urls.re_path()` sebagai alternatifnya. Dalam [catatan rilis Django 4.0](https://docs.djangoproject.com/en/4.0/releases/4.0/), API yang sama muncul di bawah fitur yang dihapus setelah menyelesaikan siklus penghentian penggunaannya. Kedua entri ini menetapkan urutan: deprecated di 3.1, dihapus di 4.0.

Jangan menyimpulkan tanggal rilis atau batas waktu penghapusan dari pemberitahuan penghentian penggunaan kecuali proyek tersebut menyatakannya. Proyek berbeda-beda dalam hal berapa lama mereka mempertahankan antarmuka yang deprecated, dan beberapa mempertahankan kompatibilitas untuk waktu yang lama. Ketika catatan rilis menyatakan bahwa API dihapus, verifikasi apakah entri tersebut berlaku untuk seluruh API atau menyebutkan pengecualian. Django 4.0, misalnya, menyatakan `NullBooleanField` telah dihapus kecuali untuk dukungan dalam migrasi historis. Pengecualian tersebut penting bagi pengelola yang bekerja dengan berkas migrasi lama.

Bagian 3

Periksa panduan migrasi sebelum mengubah kode

Pengganti mungkin terlihat serupa tetapi memiliki perilaku atau persyaratan yang berbeda. Ikuti halaman migrasi yang ditautkan dari catatan rilis, lalu periksa referensi berversi dari pengganti tersebut. [Panduan peningkatan versi](https://docs.djangoproject.com/en/4.0/howto/upgrade-version/) Django merekomendasikan untuk menyelesaikan peringatan deprecation pada versi saat ini sebelum melanjutkan peningkatan. Saran tersebut mengubah pemeriksaan dokumentasi yang samar menjadi urutan praktis: tingkatkan dalam langkah-langkah yang didukung, munculkan peringatan, perbaiki penggunaan proyek sendiri, dan baru kemudian beralih ke versi tempat penghapusan berlaku.

Untuk contoh URL Django, `re_path()` adalah pengganti yang terdokumentasi. Validasi jalur impor dan perilaku terhadap dokumentasi untuk versi target. Rilis historis ini mengilustrasikan perubahan tersebut; ini bukan rekomendasi untuk menginstalnya hari ini.

Bagian 4

Pisahkan antara deprecated, dihapus, dan tersedia

Gunakan bahasa status yang tepat:

Jangan menyimpulkan adanya dukungan pemeliharaan saat ini hanya karena sebuah contoh berjalan di satu lingkungan. Konfirmasikan bahwa versi target yang tepat mendokumentasikannya sebagai tersedia dan periksa pemberitahuan deprecation pada versi-versi berikutnya. Ketersediaan dalam rilis lama tidak membuktikan bahwa rilis tersebut masih dipelihara.

Pustaka standar Python mengilustrasikan mengapa nomor versi itu penting. [Catatan "What's New" Python 3.9](https://docs.python.org/3/whatsnew/3.9.html) menyatakan alias seperti `collections.Mapping` telah memunculkan `DeprecationWarning` sejak Python 3.3 dan bahwa Python 3.9 adalah versi terakhir yang menyediakan alias kompatibilitas mundur tersebut. Catatan yang sama menyarankan pengujian dengan opsi peringatan untuk memunculkan deprecation. Artikel yang melabeli `collections.Mapping` hanya sebagai "deprecated" tanpa menyebutkan versi Python-nya membuat pembaca tidak dapat membedakan apakah mereka mendapatkan peringatan atau atribut yang hilang. Lebih pilih lokasi `collections.abc` yang terdokumentasi, dan periksa catatan rilis Python target untuk mengetahui statusnya.

**Deprecated:** Pengelola tidak menyarankan penggunaan API tersebut dan mengidentifikasi pengganti atau perubahan di masa mendatang. API ini mungkin masih berfungsi dalam rilis yang dikutip, tetapi ini merupakan sinyal migrasi.
**Dihapus (Removed):** Catatan rilis menyatakan bahwa API tidak lagi tersedia dalam versi tersebut, bergantung pada pengecualian yang dinyatakan. Kode yang mengimpor atau memanggilnya dapat gagal.
**Tersedia dalam versi target:** Konfirmasikan ketersediaan dalam referensi resmi versi tersebut.
Bagian 5

Ubah pelacakan menjadi keputusan editorial

Setelah memeriksa rantainya, pilih satu tindakan untuk artikel tersebut. Jika contoh tersebut didokumentasikan sebagai tersedia di lingkungan yang disebutkan, beri label versi dan status secara akurat. Jika deprecated tetapi masih tersedia, nyatakan dengan jelas, tunjukkan penggantinya, dan jelaskan versi mana yang perlu diantisipasi oleh pembaca. Jika dihapus, perbarui kode dan sebutkan rilis pertama saat API tersebut tidak lagi tersedia; pertahankan catatan historis hanya jika pembaca membutuhkannya untuk memahami proyek-proyek lama.

Catatan bukti yang ringkas membantu mencegah ambiguitas di masa mendatang: catat nama pasti API, rilis deprecation paling awal, rilis penghapusan jika ada, penggantinya, dan URL catatan resmi. Jika sumber resmi tidak mengidentifikasi versi penghapusan atau pengganti, nyatakan bahwa statusnya belum terselesaikan daripada mengisi celah tersebut dari cuplikan hasil salinan atau artikel yang belum diverifikasi. Hasilnya adalah koreksi spesifik per versi yang dapat ditindaklanjuti pembaca, alih-alih klaim tak berbatas waktu bahwa suatu API sudah "lama".

Bacaan terkait

Lanjutkan topik ini