Sepeda dalam pemrograman: apa itu, penyebab dan cara menghindari

Apa itu sepeda dalam pemrograman

Sepeda adalah istilah dari komunitas pengembang yang berarti menciptakan implementasi sendiri dari fungsionalitas yang sudah tersedia dalam bentuk pustaka, kerangka kerja, atau layanan jadi. Di lingkungan berbahasa Inggris digunakan ungkapan reinventing the wheel — menemukan kembali roda. Dalam bahasa Indonesia juga ditemukan varian "sepeda", "implementasi sendiri", "sepeda sendiri".

Asal-usul metafora ini terkait dengan kenyataan bahwa roda adalah salah satu penemuan tertua umat manusia. Mencoba menciptakannya kembali di abad ke-21 tidak masuk akal. Dalam pemrograman analoginya lebih tepat: pustaka jadi adalah "roda" yang telah dioptimalkan oleh ribuan insinyur selama bertahun-tahun. Menciptakan roda sendiri dengan kualitas lebih rendah — pemborosan sumber daya.

RedMonk dalam laporan analitis (2023) menghitung bahwa aplikasi komersial rata-rata menggunakan sekitar 500 dependensi eksternal. Jika pengembang menulis masing-masing sendiri, biaya proyek akan meningkat puluhan kali lipat, dan waktu pemasaran — bertahun-tahun. Ekosistem manajer paket (npm, Maven, PyPI, NuGet) ada tepat untuk menghindari menemukan kembali roda.

Tanda-tanda sepeda

Kode yang merupakan sepeda dapat dikenali dari beberapa tanda: menyelesaikan tugas standar dengan cara tidak standar, tidak memiliki tes atau dokumentasi, tidak mendukung kasus tepi yang sudah lama dipertimbangkan dalam pustaka jadi. Seringkali kode semacam itu ditulis dengan mempertimbangkan "persyaratan unik" proyek, padahal kenyataannya persyaratan ini tidak berbeda dari yang tipikal.

Perbedaan antara sepeda dan solusi kustom

Solusi kustom dibenarkan ketika pustaka jadi tidak cocok karena batasan arsitektur atau lisensi. Sepeda dibuat tanpa alasan objektif — karena keinginan "bermain", ketidakpercayaan pada kode orang lain, atau ketidaktahuan akan alat yang ada. Perbedaannya mendasar: kustom adalah pilihan sadar, sepeda adalah kesalahan.

Mengapa pengembang menciptakan sepeda

Pertama dan alasan paling umum — ketidaktahuan akan solusi yang ada. Pengembang junior mungkin tidak tahu bahwa untuk mengurai JSON di pustaka standar ada fungsi bawaan. Sebaliknya ia akan menulis pengurai secara manual. Masalah ini sangat relevan bagi pemula yang baru memasuki ekosistem bahasa.

Kedua — ilusi kontrol. Pengembang berpengalaman kadang yakin bahwa "mereka bisa menulis lebih baik" daripada penulis pustaka populer. Statistik mengatakan sebaliknya: kemungkinan kesalahan dalam pustaka yang digunakan jutaan proyek jauh lebih rendah daripada kode yang baru ditulis. Menurut Synopsys (2024), kode Open Source rata-rata mengandung 0,1 kesalahan per seribu baris, sedangkan kode korporat — 1–2.

Ketiga — kurangnya budaya penggunaan kembali. Di perusahaan yang tidak biasa meneliti solusi jadi sebelum mulai bekerja, setiap pengembang menciptakan "sepedanya sendiri". Ini menyebabkan fragmentasi kode: dalam satu proyek bisa ada tiga implementasi klien HTTP berbeda yang ditulis oleh karyawan berbeda.

Aspek psikologis

Efek IKEA — fenomena psikologis di mana seseorang menghargai apa yang ia buat sendiri lebih tinggi daripada barang jadi yang secara objektif lebih baik. Dalam pemrograman ini bermanifestasi sebagai kebanggaan pada "sepeda sendiri" dan keengganan untuk menggantinya dengan pustaka jadi bahkan dengan kelebihan yang jelas dari yang terakhir.

Konsekuensi menciptakan sepeda dalam proyek

Konsekuensi ekonomi adalah yang paling jelas. Menurut perkiraan Stripe (2022), pengembang menghabiskan hingga 35% waktu kerja untuk menciptakan kode yang sudah ada dalam bentuk solusi jadi. Dihitung dengan gaji tim 10 orang, ini sekitar 200 ribu dolar per tahun yang terbuang untuk menemukan kembali roda.

Konsekuensi teknis mencakup pertumbuhan basis kode, penurunan cakupan tes (kode sendiri biasanya diuji lebih buruk), peningkatan jumlah bug dan kerentanan. Selain itu, setiap komponen sendiri adalah titik kegagalan lain yang harus dipantau dan dipelihara.

Google dalam penelitiannya "Why Google Stores Billions of Lines of Code" (2023) mencatat bahwa bahkan di perusahaan teknologi terbesar pun ada proses ketat untuk pengambilan keputusan tentang penambahan dependensi baru atau penulisan implementasi sendiri. Sebagian besar tim internal pertama-tama mencari solusi jadi di repositori kode terpadu.

Dampak pada tim

Sepeda menciptakan asinkronisitas informasi: ketika seorang pengembang pergi, komponennya sendiri tertinggal tanpa dokumentasi dan dukungan. Anggota tim baru harus berurusan dengan kode tidak standar, membuang waktu yang bisa digunakan untuk pekerjaan produktif.

Contoh sepeda umum dalam kode

Contoh paling umum — penguraian manual JSON atau XML, padahal hampir semua bahasa modern memiliki alat bawaan. Pengembang menulis fungsi rekursif untuk melintasi pohon objek, tidak tahu bahwa JSON.parse() menyelesaikan tugas dalam satu baris.

Kedua — implementasi sendiri klien HTTP. Pustaka standar (fetch, axios, OkHttp, URLSession) mendukung caching, koneksi ulang, batas waktu, dan keamanan. Klien sendiri biasanya tidak mempertimbangkan setidaknya satu dari persyaratan ini, yang menyebabkan bug dalam produksi.

Ketiga — sistem logging sendiri alih-alih menggunakan SLF4J, Winston atau Log4j. Pengembang menghabiskan berminggu-minggu untuk menulis apa yang dilakukan pustaka jadi langsung dengan dukungan rotasi, level logging, penulisan asinkron, dan integrasi dengan sistem pemantauan.

# sepeda — penguraian CSV manual
def parse_csv(line):
    result = []
    current = ""
    for ch in line:
        if ch == ",":
            result.append(current)
            current = ""
        else:
            current += ch
    return result

# menggunakan pustaka standar sebagai gantinya
import csv
with open("data.csv") as f:
    reader = csv.reader(f)

Anti-pola ORM sendiri

Menulis ORM sendiri (Object-Relational Mapping) — mungkin sepeda paling mahal. ORM jadi seperti Hibernate, Entity Framework atau SQLAlchemy dikembangkan selama bertahun-tahun, mendukung caching, pemuatan malas, migrasi, dan puluhan DBMS. ORM sendiri biasanya terbatas pada satu basis data dan mengandung kesalahan kritis dalam manajemen koneksi.

Kapan sepeda dibenarkan

Pembelajaran — satu-satunya situasi di mana sepeda tidak hanya dibenarkan tetapi juga berguna. Menulis parser, server HTTP, atau ORM sendiri untuk tujuan pendidikan membantu memahami bagaimana alat-alat ini bekerja di balik layar. Penting untuk tidak mencampuradukkan proyek pendidikan dengan kode produksi: apa yang baik untuk proyek pribadi tidak dapat diterima dalam pengembangan komersial.

Persyaratan unik memang mungkin memerlukan implementasi sendiri. Jika tidak ada pustaka yang mendukung protokol, format data, atau platform perangkat keras tertentu — membuat solusi kustom dibenarkan. Tetapi pertama-tama pastikan tugas itu benar-benar unik, bukan hanya kurang diteliti.

Batasan lisensi — alasan sah lainnya. Beberapa lisensi Open Source (GPL, AGPL) mungkin tidak kompatibel dengan model bisnis perusahaan. Dalam kasus seperti itu, pengembangan implementasi sendiri dengan lisensi yang lebih permisif dibenarkan.

Aturan tiga percobaan

Ada aturan praktis: sebelum menulis implementasi sendiri, cobalah temukan dan uji tiga solusi jadi yang berbeda. Jika tidak ada yang cocok — buat sendiri, tetapi dokumentasikan mengapa varian yang ada ditolak. Ini melindungi dari penemuan kembali roda secara tidak sadar.

Cara menghindari pembuatan sepeda

Langkah pertama — membentuk kebiasaan mencari solusi jadi sebelum mulai mengerjakan tugas tipikal apa pun. Gunakan pencarian di manajer paket, GitHub, Stack Overflow. Waktu yang dihabiskan untuk penelitian akan kembali berlipat ganda berkat tidak menulis kode sendiri.

Langkah kedua — menerapkan tinjauan kode dengan fokus pada deteksi sepeda. Saat meninjau, ajukan pertanyaan: "Mengapa kita tidak menggunakan pustaka jadi untuk tugas ini?" Jika jawaban tidak mengandung alasan objektif — ini sepeda. Di perusahaan besar (Google, Meta), tinjauan kode mencakup pemeriksaan wajib penemuan kembali roda.

Langkah ketiga — membuat daftar pengetahuan internal. Dokumentasikan pustaka dan alat apa yang digunakan dalam proyek, tugas apa yang mereka selesaikan. Pengembang baru harus memiliki akses ke informasi ini agar tidak menciptakan sepeda karena ketidaktahuan. Buatlah daftar keputusan arsitektur yang diambil (ADR) dengan justifikasi pilihan.

• Teliti manajer paket sebelum memulai tugas baru
• Periksa pustaka standar bahasa — mencakup 80% tugas tipikal
• Gunakan tinjauan kode untuk mendeteksi sepeda
• Dokumentasikan keputusan yang diambil tentang pemilihan pustaka
• Perbarui pengetahuan tentang ekosistem di konferensi dan blog

Sindrom Not Invented Here

Sindrom NIH (Not Invented Here — "tidak ditemukan di sini") — prasangka organisasi terhadap penggunaan solusi eksternal. Perusahaan dengan sindrom NIH lebih suka mengembangkan semuanya sendiri, menolak pustaka Open Source bahkan ketika mereka melampaui pengembangan sendiri. Sindrom ini adalah versi korporat dari sepeda.

Contoh klasik — Netscape pada akhir 1990-an, ketika perusahaan menghabiskan bertahun-tahun menulis ulang peramban dari awal alih-alih mengembangkan basis kode yang ada. Hasilnya — kehilangan pangsa pasar dan diakuisisi oleh AOL. Sebaliknya, Android dibangun di atas kernel Linux dan menggunakan ribuan komponen Open Source — ini memungkinkan produk diluncurkan ke pasar dalam waktu rekor.

Penelitian Harvard Business Review (2023) menunjukkan bahwa perusahaan dengan tingkat sindrom NIH rendah meluncurkan produk 40% lebih cepat dan menghabiskan 30% lebih sedikit untuk pengembangan. Budaya penggunaan kembali kode adalah keunggulan kompetitif dalam pengembangan perangkat lunak modern.

// sepeda — implementasi pengurutan sendiri
function bubbleSort(arr) {
  for (let i = 0; i < arr.length; i++) {
    for (let j = 0; j < arr.length - i - 1; j++) {
      if (arr[j] > arr[j + 1]) {
        [arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];
      }
    }
  }
  return arr;
}

// pengurutan bawaan — solusi standar
arr.sort((a, b) => a - b);