Komunitas pengembangan perangkat lunak semakin mempertanyakan kebijaksanaan konvensional bahwa dependensi eksternal selalu lebih baik daripada membangun solusi secara internal. Semakin banyak developer yang menolak stigma sindrom Not Invented Here ( NIH ), dengan berargumen bahwa menulis kode kustom seringkali lebih hemat biaya dibandingkan mengadopsi library pihak ketiga.
Biaya Tersembunyi dari Dependensi
Meskipun dependensi menjanjikan fungsionalitas gratis, developer menemukan bahwa dependensi tersebut datang dengan biaya tersembunyi yang signifikan. Mempelajari library yang kompleks seringkali membutuhkan waktu lebih lama daripada menulis solusi kustom yang sederhana. Perubahan yang merusak dalam dependensi dapat memicu penulisan ulang kode yang ada dengan biaya mahal. Deployment menjadi rumit ketika beberapa dependensi perlu dibundel dan didistribusikan ke mesin klien.
Kompleksitasnya berlipat ganda ketika sistem containerization dan bundling diperkenalkan semata-mata untuk mengelola rantai dependensi. Banyak tim pengembangan mendapati diri mereka menghabiskan lebih banyak waktu mengelola infrastruktur deployment daripada membangun fitur aplikasi inti mereka.
Faktor Risiko Ketergantungan
Ketergantungan Komersial:
- Insentif vendor lock-in
- Sumber dukungan tunggal
- Risiko kontinuitas bisnis
- Biaya jangka panjang yang lebih tinggi
Biaya Ketergantungan Umum:
- Investasi waktu pembelajaran
- Manajemen perubahan yang merusak
- Kompleksitas deployment
- Risiko keamanan supply chain
- Implikasi performa
Kerangka Kerja untuk Keputusan Dependensi yang Cerdas
Diskusi komunitas telah menyoroti lima kriteria kunci untuk mengevaluasi dependensi: ubiquitas, stabilitas, kedalaman, ergonomis, dan kedap air. Ubiquitas mengacu pada seberapa luas ketersediaan dependensi di seluruh lingkungan target. Stabilitas mengukur seberapa sering perubahan yang merusak terjadi. Kedalaman mempertimbangkan seberapa banyak fungsionalitas dasar yang akan sulit untuk direplikasi. Ergonomis mengevaluasi kenyamanan API. Kedap air menguji apakah abstraksi tersebut membocorkan detail implementasi.
Salah satu teknik untuk membuat perangkat lunak lebih robust adalah meminimalkan apa yang menjadi dependensi perangkat lunak Anda – semakin sedikit yang bisa salah, semakin sedikit yang akan salah.
Developer mencatat bahwa pendukung dependensi biasanya hanya fokus pada ergonomis sambil mengabaikan faktor-faktor krusial lainnya.
Contoh Evaluasi Dependencies yang Baik
Panggilan Sistem POSIX:
- Ubiquitas: Tersedia di Linux, Android, macOS, BSDs
- Stabilitas: Sangat stabil, jarang terjadi perubahan yang merusak
- Kedalaman: Satu panggilan menyembunyikan ratusan ribu baris kode kernel
- Ergonomis: Biasa saja (konvensi C, banyak flag)
- Kedap Air: Sebagian besar baik dengan pengecualian kecil pada perangkat penyimpanan
Platform Web (HTML, CSS, JS, Web APIs):
- Ubiquitas: Platform yang paling banyak digunakan secara global
- Stabilitas: Komitmen kuat terhadap kompatibilitas mundur
- Kedalaman: Menulis browser kustom tidak dapat dilakukan
- Ergonomis: Memadai dengan dokumentasi yang sangat baik
- Kedap Air: Baik kecuali untuk interaksi file/audio/video
Dependensi Komersial Mendapat Pengawasan Ketat
Dependensi berbayar menghadapi skeptisisme khusus dari komunitas developer. Solusi komersial menciptakan risiko vendor lock-in, karena perusahaan memiliki insentif finansial untuk membuat perpindahan menjadi mahal. Ketika vendor bangkrut atau menghentikan dukungan, proyek yang bergantung pada solusi mereka menghadapi risiko kontinuitas yang serius. Alternatif open source, meskipun tidak sempurna, umumnya menawarkan stabilitas jangka panjang dan dukungan komunitas yang lebih baik.
Pendekatan Dependensi Minimal yang Sukses
Contoh dunia nyata menunjukkan viabilitas strategi dependensi minimal. TigerBeetle , sebuah database keuangan, beroperasi dengan kebijakan nol dependensi di luar toolchain intinya. Pendekatan ini menghilangkan risiko serangan supply chain, meningkatkan performa, dan mengurangi kompleksitas instalasi.
Strategi ini bekerja dengan baik terutama untuk infrastruktur dasar, di mana biaya dependensi teramplifikasi di seluruh stack teknologi. Tim yang mengadopsi pendekatan ini berinvestasi besar dalam menguasai tools inti pilihan mereka daripada mempelajari beberapa framework khusus.
Menemukan Keseimbangan yang Tepat
Diskusi ini tidak mengadvokasi penghindaran dependensi secara total. Standar seperti system calls POSIX , kode kontrol terminal, dan API platform web merepresentasikan dependensi yang sangat baik karena ubiquitas, stabilitas, dan kedalamannya. Ini menyediakan fungsionalitas masif yang tidak praktis untuk diciptakan ulang sambil mempertahankan kompatibilitas yang luas.
Kuncinya terletak pada evaluasi kritis. Setiap keputusan dependensi harus menimbang biaya terhadap manfaat, mempertimbangkan pemeliharaan jangka panjang, kompleksitas deployment, dan persyaratan khusus proyek. Manajemen dependensi yang cerdas berarti memilih dengan bijak daripada default ke solusi eksternal.
Referensi: NIH Is Far Cheaper Than The Wrong Dependency