Kebun binatang teknologi dalam proyek: apa itu, penyebab dan metode

Apa itu kebun binatang teknologi dalam proyek

Kebun binatang teknologi — situasi ketika dalam satu proyek atau perusahaan digunakan terlalu banyak alat berbeda untuk menyelesaikan tugas yang sama. Misalnya, tiga klien HTTP berbeda (Alamofire, OkHttp, Ktor), dua manajer status (Redux, MobX), dan tiga basis data (Realm, CoreData, SQLite).

Perbedaan antara kebun binatang dan pilihan sadar alat berbeda untuk tugas berbeda adalah tidak adanya strategi. Jika tim A memilih React Native, tim B — Flutter, dan tim C — Kotlin Multiplatform tanpa keputusan bersama — ini adalah kebun binatang. Keragaman itu sendiri tidak berbahaya, yang berbahaya adalah ketidakterkendaliannya.

Setiap tumpukan baru dalam proyek meningkatkan beban kognitif pengembang. Untuk bekerja secara efektif, mereka harus mengingat nuansa semua teknologi yang digunakan. Menurut data Google (2024), peralihan konteks antara tumpukan berbeda mengurangi produktivitas pengembang sebesar 23% dibandingkan dengan bekerja di lingkungan teknologi yang seragam.

Penyebab munculnya kebun binatang teknologi

Keputusan terdesentralisasi — penyebab utama. Setiap tim memilih teknologi untuk proyeknya sendiri tanpa memperhatikan strategi umum. Tim backend menggunakan Kotlin, tim ML — Python, tim mobile — Flutter. Secara terpisah, keputusan itu benar, tetapi bersama-sama mereka menciptakan kebun binatang.

Merger dan akuisisi — ketika perusahaan mengakuisisi perusahaan lain, tumpukan teknologi bergabung. Dua sistem menyelesaikan tugas yang sama dengan cara berbeda. Contoh: setelah membeli startup, perusahaan besar mendapatkan tumpukannya di Ruby on Rails, meskipun standar internalnya adalah Java Spring. Muncul pertanyaan: menulis ulang atau memelihara dua tumpukan secara paralel.

Perubahan teknologi trendi — setiap siklus hype menambahkan tumpukan baru. Pada 2015 semua orang menulis di AngularJS, pada 2017 — di React, pada 2020 — di Svelte. Tanpa disiplin, proyek mengumpulkan lapisan dari era berbeda. Modul warisan yang berfungsi tetapi tidak dipelihara menambah keragaman tanpa kemungkinan eliminasi cepat.

Mengapa kebun binatang berbahaya bagi tim dan bisnis

Orientasi pengembang baru berubah menjadi mempelajari 5+ teknologi berbeda daripada satu. Alih-alih seminggu untuk mengenal proyek, pemula menghabiskan sebulan untuk menguasai semua alat yang digunakan. Waktu mencapai produktivitas meningkat sebanding dengan jumlah tumpukan dalam proyek.

Peralihan konteks — pengembang yang bekerja dengan 3+ tumpukan sepanjang hari kehilangan hingga 30% waktu untuk memulihkan konteks setelah setiap peralihan. Menurut data University of California (2023), setelah setiap peralihan diperlukan 23 menit untuk kembali ke tingkat produktivitas awal. Dengan 5 peralihan per hari — hampir 2 jam hilang.

Risiko keamanan — setiap tumpukan memerlukan pembaruan, pemantauan kerentanan, dan pengetahuan praktik terbaik. Tim tidak bisa menjadi ahli di semua teknologi secara bersamaan. Kelelahan ketergantungan — ketika jumlah pustaka yang digunakan melebihi kemampuan tim untuk melacak dan memperbaruinya — merupakan ancaman langsung bagi keamanan produk.

Kompleksitas infrastruktur — CI/CD harus dikonfigurasi untuk setiap tumpukan. Sistem build yang berbeda (Gradle, CocoaPods, npm, pip), persyaratan lingkungan yang berbeda. Tim infrastruktur menghabiskan sumber daya untuk memelihara pipeline yang beragam daripada meningkatkannya.

Cara mendiagnosis masalah dalam proyek

Inventarisasi tumpukan — buat daftar lengkap teknologi yang digunakan: bahasa, framework, basis data, CI/CD, sistem pemantauan. Untuk setiap teknologi, tandai jumlah proyek/modul, tingkat dukungan, dan jumlah pengembang yang menguasainya di tingkat profesional.

Technology Radar — metode ThoughtWorks yang membagi teknologi menjadi 4 kuadran: Adopt, Trial, Assess, Hold. Adopt — tumpukan yang direkomendasikan, Trial — eksperimental, Assess — dalam evaluasi, Hold — tidak direkomendasikan untuk digunakan. Contoh: Flutter di Adopt, React Native di Hold — tim tahu apa yang harus dipilih.

Metrik biaya pemeliharaan — perkirakan berapa jam rekayasa per bulan dihabiskan untuk memelihara setiap tumpukan. Jika tumpukan mengonsumsi 10% sumber daya tetapi digunakan di 2% modul — ia adalah kandidat untuk diganti. Peta panas tumpukan: sumbu ‘jumlah proyek’ vs ‘kompleksitas pemeliharaan’ menunjukkan area bermasalah.

Metode standarisasi tumpukan teknologi

Catatan Keputusan Arsitektur (ADR) — mendokumentasikan keputusan arsitektur dengan justifikasi pemilihan teknologi. Setiap ADR berisi konteks, alternatif yang dipertimbangkan, dan argumen yang mendukung pilihan. Michael Nygard (2022) mempopulerkan pendekatan ini dan hari ini ADR adalah standar bagi tim yang mengontrol keragaman teknologi.

Komite Peninjau Teknologi — komisi pengembang senior yang menyetujui teknologi baru dalam proyek. Keputusan dibuat berdasarkan kriteria: kompatibilitas dengan tumpukan yang ada, dukungan komunitas, biaya migrasi, ketersediaan bakat. Spotify menggunakan komite serupa sejak 2018.

Gerbang untuk proyek baru — aturan: setiap layanan atau modul baru hanya menggunakan tumpukan yang disetujui. Pengecualian dimungkinkan melalui ADR dengan justifikasi. Contoh: layanan mikro baru dapat ditulis dalam Kotlin hanya jika tim membuktikan bahwa Java tidak cocok untuk tugas ini. Penggunaan teknologi apa pun tanpa hambatan dilarang.

Pengurangan bertahap keragaman tumpukan

Fase 1: Pembekuan — proyek baru pada tumpukan yang tidak didukung dihentikan. Untuk setiap tumpukan dari kuadran Hold ditetapkan tanggal akhir masa pakai. Fungsionalitas baru hanya ditulis pada tumpukan yang disetujui. Modul warisan tetap berfungsi tetapi tidak dikembangkan.

Fase 2: Konsolidasi — untuk setiap tugas dipilih satu alat. Satu klien HTTP, satu manajer status, satu basis data. Modul pada tumpukan alternatif direncanakan untuk migrasi berdasarkan prioritas. Pola Strangler Fig — metode utama penggantian tanpa menghentikan sistem.

Fase 3: Migrasi — setiap sprint tim mengalokasikan 20% waktu untuk menulis ulang modul kritis dari tumpukan usang ke yang disetujui. Arsitektur target ditetapkan dalam dokumen dan tidak berubah tanpa keputusan komite. Proses berlangsung dari 6 hingga 24 bulan tergantung pada ukuran kebun binatang.

Contoh: migrasi klien HTTP

// Sebelum: 3 klien HTTP berbeda dalam satu proyek
class HttpClientResolver {
    def resolve(moduleName) {
        switch(moduleName) {
            case "payments": return new OkHttpClient()
            case "chat": return new KtorClient()
            case "analytics": return new RetrofitClient()
        }
    }
}