Projelerde Teknoloji Hayvanat Bahçesi: Nedir, Nedenleri ve Çözümler

Bir Projede Teknoloji Hayvanat Bahçesi Nedir

Teknoloji Hayvanat Bahçesi, bir proje veya şirketin aynı görevi çözen aşırı sayıda heterojen araç kullandığı bir durumdur. Örneğin, üç farklı HTTP istemcisi (Alamofire, OkHttp, Ktor), iki durum yöneticisi (Redux, MobX) ve üç veritabanı (Realm, CoreData, SQLite).

Bir hayvanat bahçesi ile farklı görevler için farklı araçların bilinçli seçimi arasındaki fark, bir stratejinin olmamasıdır. Ekip A React Native'i seçerse, ekip B Flutter'ı seçerse ve ekip C ortak bir karar olmadan Kotlin Multiplatform'u seçerse — bu bir hayvanat bahçesidir. Çeşitliliğin kendisi zararlı değildir; kontrolsüz doğası zararlıdır.

Projedeki her yeni stack, geliştiriciler için bilişsel yükü artırır. Etkili bir şekilde çalışmak için, kullanılan tüm teknolojilerin nüanslarını hatırlamak gerekir. Google (2024)'e göre, farklı stack'ler arasında bağlam değiştirme, birleşik bir teknoloji ortamında çalışmaya kıyasla geliştirici verimliliğini %23 azaltır.

Teknoloji Hayvanat Bahçesinin Nedenleri

Merkezi olmayan kararlar ana nedendir. Her ekip, genel stratejiyi dikkate almadan kendi projesi için teknolojiler seçer. Backend ekibi Kotlin kullanır, ML ekibi Python kullanır, mobil ekip Flutter kullanır. Bireysel olarak kararlar doğrudur, ancak birlikte bir hayvanat bahçesi oluştururlar.

Birleşmeler ve Satın Almalar (M&A) — bir şirket başka bir şirketi satın aldığında, teknoloji stack'leri birleşir. İki sistem aynı sorunları farklı şekillerde çözer. Örnek: bir startup satın alındıktan sonra, büyük bir şirket iç standardı Java Spring olmasına rağmen Ruby on Rails stack'ini alır. Soru ortaya çıkar: yeniden yazmak mı yoksa iki stack'i paralel olarak sürdürmek mi?

Değişen trend teknolojiler — her hype döngüsü yeni bir stack ekler. 2015'te herkes AngularJS ile yazıyordu, 2017'de — React ile, 2020'de — Svelte ile. Disiplin olmadan, bir proje farklı dönemlerden katmanlar biriktirir. Çalışan ancak desteklenmeyen eski modüller, hızla ortadan kaldırma imkanı olmadan heterojenlik ekler.

Bir Hayvanat Bahçesi Neden Ekip ve İş İçin Tehlikelidir

Yeni geliştiricilerin onboarding'i, bir yerine 5+ farklı teknoloji öğrenmeye dönüşür. Projeye alışmak için bir hafta yerine, yeni bir kişi kullanılan tüm araçlarda ustalaşmak için bir ay harcar. Verimliliğe kadar geçen süre, projedeki stack sayısıyla orantılı olarak artar.

Bağlam değiştirme — gün içinde 3+ stack ile çalışan bir geliştirici, her değişiklikten sonra bağlamı geri yüklemek için zamanın %30'una kadarını harcar. California Üniversitesi (2023)'ne göre, her değişiklikten sonra orijinal verimlilik seviyesine dönmek 23 dakika alır. Günde 5 değişiklikle — neredeyse 2 saat kayıp.

Güvenlik riskleri — her stack güncellemeler, güvenlik açığı izleme ve en iyi uygulamalar bilgisi gerektirir. Bir ekip aynı anda tüm teknolojilerde uzman olamaz. Bağımlılık yorgunluğu — kullanılan kütüphane sayısı ekibin bunları takip etme ve güncelleme yeteneğini aştığında — ürün güvenliği için doğrudan bir tehdittir.

Altyapı karmaşıklığı — CI/CD her stack için yapılandırılmalıdır. Farklı derleme sistemleri (Gradle, CocoaPods, npm, pip), farklı ortam gereksinimleri. Altyapı ekibi, bunları iyileştirmek yerine heterojen pipeline'ları sürdürmek için kaynak harcar.

Bir Projedeki Sorun Nasıl Teşhis Edilir

Stack envanteri — kullanılan teknolojilerin tam listesini derleyin: diller, framework'ler, veritabanları, CI/CD, izleme sistemleri. Her teknoloji için proje/modül sayısını, destek seviyesini ve profesyonel düzeyde yetkin geliştirici sayısını not edin.

Technology Radar — ThoughtWorks'in teknolojileri 4 çeyreğe ayıran yöntemi: Adopt, Trial, Assess, Hold. Adopt — önerilen stack'ler, Trial — deneysel, Assess — değerlendirmede, Hold — kullanım için önerilmez. Örnek: Flutter Adopt'te, React Native Hold'da — ekipler neyi seçeceklerini anlar.

Bakım maliyeti metriği — her stack'in bakımı için ayda kaç mühendislik saati harcandığını tahmin edin. Bir stack kaynakların %10'unu tüketiyor ancak modüllerin %2'sinde kullanılıyorsa — değiştirme adayıdır. Eksenleri "proje sayısı" vs "bakım karmaşıklığı" olan bir stack ısı haritası, sorunlu alanları açıkça gösterir.

Teknoloji Stack'ini Standardize Etme Yöntemleri

Architecture Decision Records (ADR) — teknoloji seçimlerinin gerekçesiyle birlikte mimari kararların belgelenmesi. Her ADR, bağlam, değerlendirilen alternatifler ve seçim lehine argümanlar içerir. Michael Nygard (2022) bu yaklaşımı popüler hale getirmiştir ve bugün ADR, teknoloji çeşitliliğini kontrol eden ekipler için bir standarttır.

Technology Review Board — projedeki yeni teknolojileri onaylayan kıdemli geliştiricilerden oluşan bir komite. Kararlar, mevcut stack ile uyumluluk, topluluk desteği, taşıma maliyeti, yetenek bulunabilirliği gibi kriterlere göre alınır. Spotify 2018'den beri benzer bir komite kullanmaktadır.

Yeni projeler için geçit — kural: herhangi bir yeni hizmet veya modül yalnızca onaylanmış stack'i kullanır. İstisnalar, gerekçeli ADR aracılığıyla mümkündür. Örnek: yeni bir mikro hizmet, yalnızca ekip Java'nın bu görev için uygun olmadığını kanıtlarsa Kotlin ile yazılabilir. Herhangi bir teknolojinin engelsiz kullanımı yasaktır.

Stack Çeşitliliğinin Aşamalı Azaltılması

Aşama 1: Dondurma — desteklenmeyen stack'lerdeki yeni projeler durdurulur. Hold çeyreğindeki her stack için bir kullanım ömrü sonu tarihi belirlenir. Yeni işlevsellik yalnızca onaylanmış stack'lerde yazılır. Eski modüller çalışmaya devam eder ancak genişletilmez.

Aşama 2: Konsolidasyon — her görev için bir araç seçilir. Bir HTTP istemcisi, bir durum yöneticisi, bir veritabanı. Alternatif stack'lerdeki modüller önceliğe göre taşınma için planlanır. Strangler Fig deseni, sistem kesintisi olmadan değiştirme için ana yöntemdir.

Aşama 3: Taşıma — her sprintte ekip, kritik modülleri eski stack'lerden onaylanmış olanlara yeniden yazmak için zamanın %20'sini ayırır. Hedef mimari belgelenir ve komite kararı olmadan değişmez. Süreç, hayvanat bahçesinin ölçeğine bağlı olarak 6 ila 24 ay sürer.

Örnek: HTTP İstemci Taşıması

// Before: 3 different HTTP clients in one project
class HttpClientResolver {
    def resolve(moduleName) {
        switch(moduleName) {
            case "payments": return new OkHttpClient()
            case "chat": return new KtorClient()
            case "analytics": return new RetrofitClient()
        }
    }
}