Technológiai állatkert a projektekben: mi ez, okok és módszerek

Mi a technológiai állatkert egy projektben

Technológiai állatkert — olyan helyzet, amikor egy projektben vagy cégnél túlzottan sokféle eszközt használnak ugyanazon feladat megoldására. Például három különböző HTTP kliens (Alamofire, OkHttp, Ktor), két állapotkezelő (Redux, MobX) és három adatbázis (Realm, CoreData, SQLite).

Az állatkert és a tudatos eszközválasztás közötti különbség a stratégia hiánya. Ha az A csapat a React Native-t választja, a B csapat a Flutter-t, a C csapat pedig a Kotlin Multiplatform-ot közös döntés nélkül — ez állatkert. A változatosság önmagában nem káros, a káros az ellenőrizetlensége.

Minden új verem a projektben növeli a fejlesztők kognitív terhelését. A hatékony munkához emlékezniük kell az összes használt technológia árnyalataira. A Google (2024) adatai szerint a kontextusváltás a különböző vermek között 23%-kal csökkenti a fejlesztő termelékenységét az egységes technológiai környezetben végzett munkához képest.

A technológiai állatkert kialakulásának okai

Decentralizált döntések — a fő ok. Minden csapat a saját projektjéhez választ technológiákat az általános stratégia figyelmen kívül hagyásával. A backend csapat Kotlin-t, az ML csapat Python-t, a mobil csapat Flutter-t használ. Külön-külön a döntések helyesek, de együtt állatkertet hoznak létre.

Felvásárlások és összeolvadások — amikor egy cég felvásárol egy másikat, a technológiai vermek egyesülnek. Két rendszer ugyanazokat a feladatokat különböző módon oldja meg. Példa: egy startup felvásárlása után a nagy cég megkapja annak Ruby on Rails vermét, miközben a belső szabvány a Java Spring. Felmerül a kérdés: átírni vagy két vermet párhuzamosan fenntartani.

Divatos technológiák változása — minden hype ciklus új vermet ad hozzá. 2015-ben mindenki AngularJS-ben írt, 2017-ben — React-ben, 2020-ban — Svelte-ben. Fegyelem nélkül a projekt különböző korszakok rétegeit gyűjti össze. A működő, de nem karbantartott örökség modulok változatosságot adnak hozzá a gyors eltávolítás lehetősége nélkül.

Miért veszélyes az állatkert a csapatra és az üzletre

Az új fejlesztők betanulása 5+ különböző technológia megtanulásává válik egy helyett. Ahelyett, hogy egy hét alatt megismerkedne a projekttel, a kezdő egy hónapot tölt az összes eszköz elsajátításával. A termelékenység elérésének ideje a projektben lévő vermek számával arányosan nő.

Kontextusváltás — a 3+ veremmel dolgozó fejlesztő akár 30% időt veszít a kontextus helyreállítására minden váltás után. A University of California (2023) adatai szerint minden váltás után 23 percre van szükség az eredeti termelékenységi szinthez való visszatéréshez. Napi 5 váltásnál — majdnem 2 óra veszteség.

Biztonsági kockázatok — minden verem frissítéseket, sebezhetőségek figyelését és legjobb gyakorlatok ismeretét igényli. A csapat nem lehet egyszerre minden technológiában szakértő. A függőségi fáradtság — amikor a használt könyvtárak száma meghaladja a csapat képességét azok követésére és frissítésére — közvetlen fenyegetés a termék biztonságára.

Infrastruktúra összetettsége — a CI/CD-t minden veremhez konfigurálni kell. Különböző build rendszerek (Gradle, CocoaPods, npm, pip), eltérő környezeti követelmények. Az infrastruktúra csapat erőforrásokat fordít a különböző pipeline-ok karbantartására ahelyett, hogy azokat fejlesztené.

Hogyan diagnosztizáljuk a problémát egy projektben

Verem leltár — készítsen teljes listát a használt technológiákról: nyelvek, keretrendszerek, adatbázisok, CI/CD, megfigyelő rendszerek. Minden technológiánál jelölje meg a projektek/modulok számát, a támogatás szintjét és a szakmai szinten birtokló fejlesztők számát.

Technology Radar — a ThoughtWorks módszere, amely 4 kvadránsra osztja a technológiákat: Adopt, Trial, Assess, Hold. Adopt — ajánlott vermek, Trial — kísérleti, Assess — értékelés alatt, Hold — használata nem ajánlott. Példa: Flutter az Adopt-ban, React Native a Hold-ban — a csapatok tudják, mit válasszanak.

Karbantartási költség metrika — becsülje meg, hány mérnöki órát fordítanak havonta az egyes vermek karbantartására. Ha egy verem 10% erőforrást fogyaszt, de a modulok 2%-ában használják — cserejelölt. A verem ‘projektek száma’ vs ‘karbantartás összetettsége’ hőtérképe szemléletesen mutatja a problémás területeket.

A technológiai verem szabványosításának módszerei

Architektúra Döntési Nyilvántartások (ADR) — az architektúra döntések dokumentálása a technológiaválasztás indoklásával. Minden ADR tartalmazza a kontextust, a megfontolt alternatívákat és a választás melletti érveket. Michael Nygard (2022) népszerűsítette ezt a megközelítést, és ma az ADR szabvány a technológiai változatosságot ellenőrző csapatok számára.

Technológiai Felülvizsgáló Bizottság – vezető fejlesztőkből álló bizottság, amely jóváhagyja az új technológiákat a projektben. A döntés kritériumok alapján történik: kompatibilitás a meglévő veremmel, közösségi támogatás, migrációs költség, tehetség elérhetősége. A Spotify 2018 óta használ hasonló bizottságot.

Kapu új projektek számára — szabály: minden új szolgáltatás vagy modul csak a jóváhagyott vermet használja. Kivételek ADR-en keresztül indoklással lehetségesek. Példa: új mikroszolgáltatást Kotlin-ban csak akkor lehet írni, ha a csapat bizonyítja, hogy a Java nem alkalmas erre a feladatra. Bármilyen technológia korlátlan használata tilos.

A vermek változatosságának fokozatos csökkentése

1. fázis: Befagyasztás — az új projektek nem támogatott vermeken leállnak. Minden Hold kvadránsban lévő veremhez élettartam vége dátumot állapítanak meg. Új funkciók csak a jóváhagyott vermeken íródnak. Örökség modulok tovább működnek, de nem fejlesztik őket.

2. fázis: Konszolidáció — minden feladathoz egy eszközt választanak. Egy HTTP kliens, egy állapotkezelő, egy adatbázis. Az alternatív vermeken lévő modulokat prioritás szerint tervezik migrálni. A Strangler Fig minta — a csere fő módszere a rendszer leállítása nélkül.

3. fázis: Migráció — minden sprintben a csapat az idő 20%-át fordítja a kritikus modulok átírására az elavult vermekről a jóváhagyottakra. A cél architektúra dokumentumban rögzítve van, és a bizottság döntése nélkül nem változik. A folyamat az állatkert méretétől függően 6-24 hónapig tart.

Példa: HTTP kliensek migrációja

// Előtte: 3 különböző HTTP kliens egy projektben
class HttpClientResolver {
    def resolve(moduleName) {
        switch(moduleName) {
            case "payments": return new OkHttpClient()
            case "chat": return new KtorClient()
            case "analytics": return new RetrofitClient()
        }
    }
}