Over-Dependent with External Libraries or Packages: Why You Shouldn’t Do That

Wahyu Ivan
6 min readApr 1, 2024

--

Image Source: https://miro.medium.com/v2/resize:fit:1060/1*-ccpoehy968EMDfBbR_MoQ.png

Halo teman-teman. Kali ini aku bakal bawain tulisan seputar self improvement buat developer yak. Tulisan ini merupakan kumpulan pengalamanku dan pembelajaran yang aku dapatkan selama mengembangkan software. Tulisan ini aku buat karena terinspirasi oleh keributan di Twitter seputar masalah “over-relying on other people’s code” alias terlalu bergantung ke kode orang lain entah itu lewat menginstall library atau package.

Screenshot Rujukan Twitter yang Menjadi Inspirasi Tulisan Ini

Pengantar

Mari ke basic-nya dulu sebelum ke penjelasan lebih lanjutnya. Jadi pengertian dari external package/library adalah sebuah kode third-party (yang dibuat oleh orang lain) yang dibuat dengan tujuan untuk meng-extend fungsionalitas kode agar bisa digunakan oleh orang lain. Biasanya package/library dibuat dengan tujuan spesifik untuk memecahkan suatu masalah, contoh library Keras yang digunakan untuk memecahkan permasalahan yang berhubungan dengan deep-learning.

Sebenarnya, tidak ada yang salah jika kalian menggunakan external package/library, malah hal ini sangat memudahkan proses development project. Tetapi masalah mulai muncul ketika sudah mulai overuse external package/library apalagi sampai di tahap di mana ketergantungan menggunakan kode orang lain untuk memecahkan masalah yang dihadapi.

Bahkan, tahap paling parahnya yakni sampai di tahap hampir 90%~ dari kode yang ada di project merupakan kode orang lain. Hal ini menyebabkan ukuran project menjadi membengkak. Jika kalian menggunakan npm/yarn, maka ukuran folder node_modules akan jadi sangat besar, begitupun jika kalian menggunakan Composer, ukuran folder vendor akan jadi sangat besar.

Mari kita menjawab quiz sebagai refleksi bagaimana pandangan kalian jika diminta untuk develop sebuah fitur. Katakanlah kalian seorang front-end engineer dan diberikan sebuah misi untuk mengembangkan fitur yang ada di dalam gambar di bawah ini.

Studi Kasus Pengembangan Fitur Editable Table

Intinya kalian disuruh mengembangkan sebuah fitur editable table. Opsi mana di bawah ini yang menurut kalian tuh “kalian banget”? (harus jujur yak hehe)

a. Diskusikan dengan tim, estimasikan waktu pengembangan, buat task card, lalu mulai ngoding.

b. Diskusikan dengan tim, estimasikan waktu pengembangan, buat task card, lalu mulai ketik di terminal npm install react-data-grid.

Jika kalian memilih opsi a, kalian bisa aku bilang masih normal 😂 belum keterngantungan dengan kode orang lain. Namun jika kalian memilih opsi b, sebaiknya kalian bisa mulai merefleksikan diri dan bertanya mengapa bisa sampai ketergantungan dengan kode orang lain.

Permasalahan yang Muncul

Root cause yang aku lihat dari fenomena ini, terutama buat junior engineer adalah dikarenakan mereka menonton tutorial Youtube atau course-course online yang menuturkan untuk developing suatu fitur langsung dengan cara mudah yaitu import package/library (beberapa kasus saja seperti ini, tidak semuanya).

Kemudahan ini tentunya sangat buruk bagi para junior software engineer yang baru di awal-awal belajar karena mereka hanya mempelajari apa yang sudah jadi tanpa perlu melewati proses susah payahnya men-develop. Mindset yang terbentuk sebagai hasil dari ini adalah sebagai berikut.

Yep, dikit-dikit harus nginstall npm package blabla, dikit-dikit ngeluh “duh kok gaada package-nya buat masalah ini ya”. Mindset seperti ini, yaitu ketergantungan dengan kode orang lain, menjadi mengkhawatirkan karena ketergantungan seperti ini membuat mereka malas menulis kodenya sendiri dan memilih mengandalkan kode orang lain yang tinggal pakai/import. Orang-orang seperti ini hanya menunda suatu masalah sampai suatu saat masalah itu muncul ke permukaan, diwakilkan dengan gambar di bawah ini.

Belum lagi beberapa “oknum” developer yang sangat keras kepala jika dinasehati. Kalian pernah mendengar kutipan seperti ini tidak?

Don’t reinvent the wheels.

Yep, kutipan diatas merupakan kutipan yang paling sering dipakai oleh para “oknum” pemalas untuk membenarkan keputusan mereka agar bisa selalu bergantung dengan kode orang lain. “Kalau sudah ada yang buatin, kenapa harus saya buat lagi?” statement ini sangat salah untuk dilontarkan apalagi jika kalian masih junior. Justru saat masih junior lah kalian harus berusaha sebanyak mungkin “reinvent the wheels”.

Pengalaman yang kalian dapatkan ketika mencoba membuat ulang sebuah roda itu sangat powerful dan kelak akan menjadi bekal penting ketika sudah beranjak menjadi mid/senior. Bayangkan jika di tahun 2011 Taylor Otwell (founder Laravel) melontarkan statement diatas dan saat itu kondisinya sudah ada Codeigniter. Mungkin Laravel tidak akan pernah ada.

Masalah berikutnya adalah maintainability dan security concern yang ada di dalam package/library yang diinstall. Kebanyakan yang aku lihat para software engineer yang selalu ketergantungan untuk menggunakan kode orang lain tidak peduli dengan maintainability dan security concern package/library yang mereka install.

“Yang penting jadi, nda usah dipikirkan terlalu berat” statement ini sangat berbahaya mengingat maintainability dan security concern merupakan hal krusial dalam pengembangan software. Lucu aja kedengerannya jika project kalian susah di maintain dan di kemudian hari mengalami masalah yang berhubungan dengan security hanya karena mengimpor kode orang lain secara sembarangan.

The Solution

Buat temen-temen yang tidak kecanduan kode orang lain (dalam hal ini masih menggunakan package/library dengan sewajarnya) setelah membaca penuturan diatas pasti mulai kepikiran “aduh, kapan sih sebenarnya waktu yang tepat untuk menggunakan external package/library” atau “bagaimana sih cara memilih external package/library yang tepat?” tenang saja, aku akan jabarkan beberapa hal penting yang perlu kalian ketahui.

Sebelum menggunakan salah satunya (packages/library), tanyakan kepada diri sendiri dan tim kalian pertanyaan di bawah:

  1. Apakah masalah ini terlalu besar atau terlalu kompleks untuk ditangani oleh library atau package internal?
  2. Apakah saya merumuskan kueri saya dengan benar saat mencari di Google untuk mengekspresikan apa yang sebenarnya saya cari?
  3. Apa tindakan yang belum saya coba sebelum menggunakan library atau package eksternal?
  4. Kasus khusus: Beberapa layanan memerlukan Anda untuk menginstal dependensi eksternal (contoh: Inspector)

Poin penting dari berdiskusi dahulu dengan tim sebelum mengambil keputusan adalah kalian bisa berbagi pikiran dahulu sebelum memutuskan untuk melakukan sesuatu. Dalam pengembangan software, kerjasama tim yang bagus akan mempermudah pengembangan baik dari segi short-term maupun long-term.

Jika di kemudian hari ternyata kalian dan tim “terpaksa” untuk menggunakan external package/library , perhatikan beberapa hal dibawah ini dan jadikan bahan pertimbangan sebelum menginstal suatu external package/library:

  1. Tanggal publikasi & terakhir diperbarui dari package/library
  2. Jumlah open issues
  3. Versi yang didukung dengan kode kalian
  4. Fitur yang ditawarkan dan fitur tambahan yang mungkin kalian butuhkan dalam waktu dekat
  5. Apakah ada masalah kompatibilitas dengan package/library lain yang saat ini kalian sudah gunakan
  6. Seberapa banyak konten yang tersedia (Dokumentasi, Stack Overflow, Artikel)
  7. Siapa orang-orang di balik package/library tersebut
  8. Perkiraan perbaikan di masa depan untuk package/library tersebut
  9. Dukungan komunitas
  10. Status lisensi

Tetap saja, perasaan yang muncul ketika proses mencari external package/library yang tepat dan pas untuk project terasa seperti gambar di bawah ini 😂.

Selesai sudah tulisan ini. Sekali lagi yaa aku jelaskan ke kalian yang baca tulisanku ini bahwa aku tidak punya masalah sama sekali jika kalian mau menggunakan external package/library. Asal jangan saja sampai berlebihan apalagi ketergantungan hehe. Aku akan tutup tulisan ini dengan quotes:

“Using external packages/libraries is okay; just don’t overuse them to the point where 90% of your project consists of someone else’s code.”
- Wahyu

Okee sip, jadi sekian dulu pembahasan kali ini. Semoga bermanfaat bagi teman-teman dan terimakasih sudah membaca!

--

--