Sebuah aplikasi inventaris kecil membutuhkan daftar barang, pencarian, dan formulir untuk mengubah stok. Sebelum alur itu selesai, project sudah memakai library untuk mengelola state, mengambil data, menangani form, memformat tanggal, dan membuat tabel.
Masing-masing punya kegunaan. Tetapi apakah aplikasi tersebut membutuhkan seluruh kemampuannya?
Saya lebih suka menilai dependency dari pekerjaan yang diambil alihnya. Library layak ditambahkan ketika membuat perilaku aplikasi lebih mudah dibangun dan dirawat. Untuk kebutuhan sempit, kemampuan bawaan platform atau kode lokal yang jelas kadang sudah cukup.
Mulai dari alur yang benar-benar dibutuhkan
Bayangkan aplikasi inventaris tadi dipakai oleh beberapa petugas. Ini ilustrasi desain, bukan laporan implementasi project tertentu.
Pada versi awal, halaman menampilkan satu daftar barang. Pencarian hanya menyaring data yang sudah dimuat. Formulir berisi nama barang dan jumlah stok. Belum ada sinkronisasi lintas-tab, penyuntingan offline, atau tabel dengan ribuan baris.
Jika aplikasinya memakai React, teks pencarian dan status membuka formulir dapat tetap berada pada komponen yang membutuhkannya. Memasang global state manager untuk dua nilai itu menambahkan kontrak baru yang harus dipahami tanpa kebutuhan berbagi state yang jelas.
Sebaliknya, jika perubahan stok harus segera tercermin pada beberapa tampilan yang memuat data secara terpisah, persoalannya sudah berbeda. Ada konsistensi data, invalidasi cache, dan kemungkinan respons datang tidak berurutan. Library pengelola server state mulai punya pekerjaan yang konkret.
Jumlah halaman saja tidak cukup untuk menentukan pilihan. Satu halaman dengan banyak interaksi yang saling bergantung bisa lebih rumit daripada sepuluh halaman informasi.
Periksa kemampuan platform sebelum memasang paket
Kebutuhan kecil sering mempunyai jalan yang sudah tersedia. Sebagai contoh, JavaScript menyediakan
Intl.RelativeTimeFormat untuk membentuk teks waktu relatif berdasarkan locale. API ini sudah diperkenalkan di Chrome 71 pada 2018, sehingga merupakan pilihan yang sudah ada sebelum 2024 (pengumuman Chrome 71).Untuk aplikasi yang hanya perlu menampilkan “kemarin” atau “2 hari lalu”, API tersebut dapat menjadi titik awal. Namun, aplikasi tetap harus menentukan selisih waktunya dan memilih satuan yang sesuai. Pemformatan waktu relatif tidak otomatis menyelesaikan parsing tanggal, perhitungan kalender, atau aturan zona waktu.
Di sisi server, periksa juga kemampuan runtime yang sudah digunakan. Dokumentasi Node.js 20.10.0 mencatat bahwa test runner
node:test sudah stabil sejak Node.js 20. Untuk menguji fungsi perhitungan stok, ini dapat mencukupi tanpa memasang test runner tambahan. Pengujian interaksi browser mempunyai kebutuhan lain.Tetap perhatikan status setiap API secara terpisah. Pada versi Node.js yang sama,
fetch tersedia tetapi masih diberi label experimental dalam dokumentasinya. Keberadaan API bawaan belum otomatis membuatnya cocok dengan persyaratan stabilitas project.Hitung pekerjaan yang tersisa setelah memilih library
Library menghemat pekerjaan tertentu sekaligus membawa pekerjaan integrasi. Kita perlu memahami kontraknya, mengikuti perubahan versi, memeriksa kompatibilitas, serta menguji bagian aplikasi yang bergantung padanya.
Biaya itu juga berlaku pada kode buatan sendiri. Mengganti library form dengan kode lokal berarti kita mengambil tanggung jawab atas nilai input, pesan error, status pengiriman, dan perilaku saat permintaan gagal. Semakin banyak aturan yang saling terkait, semakin besar pekerjaan yang harus dipelihara.
Pada formulir inventaris sederhana, validasi bawaan HTML dapat membantu pengguna mengisi field wajib atau batas angka. Server tetap harus memvalidasi input dan memeriksa izin mengubah stok. Penyederhanaan dependency tidak mengurangi tanggung jawab tersebut.
Jika formulir kemudian mempunyai field berulang, validasi antarfield, dan kebutuhan menampilkan error dari server pada input tertentu, library form dapat mengurangi kode penghubung yang mulai berulang. Manfaatnya terlihat dari perilaku yang berhasil ditangani.
Batas kode lokal juga harus jelas
Fungsi kecil untuk menormalisasi kata pencarian bisa tetap menjadi kode lokal. Kontraknya sempit, mudah dibaca, dan bisa diuji dengan beberapa contoh yang mewakili kebutuhan.
Situasinya berubah ketika fungsi itu berkembang menjadi mesin pencarian dengan pemeringkatan, toleransi salah ketik, dan aturan bahasa. Kita sudah mengambil tanggung jawab yang jauh lebih besar. Saat itulah solusi yang sudah teruji layak diperiksa.
Saya akan lebih berhati-hati lagi pada authentication, kriptografi, dan sanitasi HTML. Sedikitnya jumlah pengguna tidak membuat kesalahan di bagian tersebut menjadi murah. Gunakan implementasi yang sesuai dan terawat, lalu periksa konfigurasi serta cara integrasinya.
Ukuran project membantu menentukan cakupan, tetapi tingkat risiko menentukan seberapa kuat jaminan yang dibutuhkan.
Tambahkan ketika alasannya bisa dijelaskan
Untuk aplikasi inventaris tadi, keputusan awal dapat sesederhana ini: state tampilan berada di komponen, pencarian memakai data yang sudah dimuat, dan formulir menangani kebutuhan input yang terbatas. Dependency lain dipilih saat muncul perilaku yang belum ditangani dengan baik.
Sebelum menambahkan paket, saya ingin bisa menjawab tiga hal: pekerjaan apa yang diambil alih, bagian mana yang tetap menjadi tanggung jawab aplikasi, dan bagaimana perilakunya akan diperiksa setelah upgrade.
Jika menghapus satu library menghasilkan ratusan baris kode rapuh, penghematan itu patut dipertanyakan. Jika menambah satu library hanya membungkus operasi sederhana tanpa manfaat yang dibutuhkan, pemasangannya juga bisa ditunda.
Project kecil memberi kesempatan untuk menjaga hubungan antara kebutuhan dan alat tetap terlihat. Setiap dependency sebaiknya mempunyai pekerjaan yang bisa ditunjuk dalam aplikasi.