Технолошки зоолошки врт у пројектима: шта је, узроци и методе

Šta je tehnološki zološki vrt u projektu

Tehnološki zološki vrt — situacija u kojoj se u jednom projektu ili kompaniji koristi prekomeran broj različitih alata koji rešavaju isti zadatak. Na primer, tri različita HTTP klijenta (Alamofire, OkHttp, Ktor), dva menadžera stanja (Redux, MobX) i tri baze podataka (Realm, CoreData, SQLite).

Razlika između zoološkog vrta i svesnog izbora različitih alata za različite zadatke leži u nedostatku strategije. Ako tim A izabere React Native, tim B — Flutter, a tim C — Kotlin Multiplatform bez zajedničke odluke — to je zoološki vrt. Raznolikost sama po sebi nije štetna, štetna je njena nekontrolisanost.

Svaki novi stek u projektu povećava kognitivno opterećenje programera. Da bi efikasno radili, moraju da pamte nijanse svih korišćenih tehnologija. Prema podacima Google (2024), prebacivanje konteksta između različitih stekova smanjuje produktivnost programera za 23% u poređenju sa radom u jedinstvenom tehnološkom okruženju.

Uzroci nastanka tehnološkog zoološkog vrta

Decentralizovane odluke — glavni uzrok. Svaki tim bira tehnologije za svoj projekt bez obzira na opštu strategiju. Backend tim koristi Kotlin, ML tim — Python, mobilni tim — Flutter. Pojedinačno su odluke ispravne, ali zajedno stvaraju zoološki vrt.

Fuzije i akvizicije — kada kompanija preuzme drugu, tehnološki stekovi se spajaju. Dva sistema rešavaju iste zadatke na različite načine. Primer: nakon kupovine startupa, velika kompanija dobija njegov stek na Ruby on Rails, iako je interni standard Java Spring. Postavlja se pitanje: prepisivati ili održavati dva steka paralelno.

Promena modernih tehnologija — svaki ciklus hajpa dodaje novi stek. 2015. svi su pisali u AngularJS, 2017. — u React, 2020. — u Svelte. Bez discipline, projekt skuplja slojeve iz različitih epoha. Legat moduli, koji rade ali se ne održavaju, dodaju raznolikost bez mogućnosti brzog uklanjanja.

Zašto je zoološki vrt opasan za tim i posao

Onboarding novih programera pretvara se u učenje 5+ različitih tehnologija umesto jedne. Umesto nedelju dana za upoznavanje sa projektom, početnik provodi mesec dana da savlada sve korišćene alate. Vreme postizanja produktivnosti raste proporcionalno broju stekova u projektu.

Prebacivanje konteksta — programer koji radi sa 3+ steka tokom dana gubi do 30% vremena na obnavljanje konteksta nakon svakog prebacivanja. Prema podacima University of California (2023), nakon svakog prebacivanja potrebno je 23 minuta da se vrati na početni nivo produktivnosti. Pri 5 prebacivanja dnevno — skoro 2 sata izgubljeno.

Bezbednosni rizici — svaki stek zahteva ažuriranja, praćenje ranjivosti i poznavanje najboljih praksi. Tim ne može biti stručan u svim tehnologijama istovremeno. Umor od zavisnosti — kada broj korišćenih biblioteka premaši sposobnost tima da ih prati i ažurira — predstavlja direktnu pretnju bezbednosti proizvoda.

Složenost infrastrukture — CI/CD se mora konfigurisati za svaki stek. Različiti sistemi izgradnje (Gradle, CocoaPods, npm, pip), različiti zahtevi okruženja. Infrastrukturni tim troši resurse na održavanje raznolikih pipeline-a umesto da ih poboljšava.

Kako dijagnostikovati problem u projektu

Inventarizacija steka — sastavite potpunu listu korišćenih tehnologija: jezike, frejmvorke, baze podataka, CI/CD, sisteme monitoringa. Za svaku tehnologiju označite broj projekata/modula, nivo podrške i broj programera koji je vladaju na profesionalnom nivou.

Technology Radar — metoda ThoughtWorks koja deli tehnologije na 4 kvadranta: Adopt, Trial, Assess, Hold. Adopt — preporučeni stekovi, Trial — eksperimentalni, Assess — u proceni, Hold — ne preporučuje se za korišćenje. Primer: Flutter u Adopt, React Native u Hold — timovi znaju šta da izaberu.

Metrika troškova održavanja — procenite koliko inženjerskih sati mesečno se troši na održavanje svakog steka. Ako stek troši 10% resursa, ali se koristi u 2% modula — kandidat je za zamenu. Toplotna mapa steka: ose „broj projekata“ vs „složenost održavanja“ slikovito pokazuje problematična područja.

Metode standardizacije tehnološkog steka

Arhitektonski zapisi odluka (ADR) — dokumentovanje arhitektonskih odluka sa obrazloženjem izbora tehnologije. Svaki ADR sadrži kontekst, razmatrane alternative i argumente u prilog izbora. Michael Nygard (2022) je popularizovao ovaj pristup i danas je ADR standard za timove koji kontrolišu tehnološku raznolikost.

Odbor za reviziju tehnologije — komisija vodećih programera koja odobrava nove tehnologije u projektu. Odluka se donosi na osnovu kriterijuma: kompatibilnost sa postojećim stekom, podrška zajednice, trošak migracije, dostupnost talenata. Spotify koristi sličan odbor od 2018. godine.

Kapija za nove projekte — pravilo: svaka nova usluga ili modul koristi samo odobreni stek. Izuzeći su mogući kroz ADR sa obrazloženjem. Primer: novi mikrousulugu možete pisati u Kotlinu samo ako tim dokaže da Java nije pogodna za ovaj zadatak. Korišćenje bilo kojih tehnologija bez barijera je zabranjeno.

Postepeno smanjenje raznolikosti stekova

Faza 1: Zamrzavanje — novi projekti na nepodržanim stekovima se obustavljaju. Za svaki stek iz Hold kvadranta postavlja se datum kraja života. Nova funkcionalnost se piše samo na odobrenim stekovima. Legat moduli nastavljaju da rade, ali se ne razvijaju.

Faza 2: Konsolidacija — za svaki zadatak se bira jedan alat. Jedan HTTP klijent, jedan menadžer stanja, jedna baza podataka. Moduli na alternativnim stekovima se planiraju za migraciju po prioritetu. Strangler Fig pattern — glavni metod zamene bez zaustavljanja sistema.

Faza 3: Migracija — svaki sprint tim izdvaja 20% vremena za prepisivanje kritičnih modula sa zastarelih stekova na odobrene. Ciljna arhitektura se fiksira u dokumentu i ne menja se bez odluke odbora. Proces traje od 6 do 24 meseca u zavisnosti od veličine zoološkog vrta.

Primer: migracija HTTP klijenata

// Пре: 3 различита HTTP клијента у једном пројекту
class HttpClientResolver {
    def resolve(moduleName) {
        switch(moduleName) {
            case "payments": return new OkHttpClient()
            case "chat": return new KtorClient()
            case "analytics": return new RetrofitClient()
        }
    }
}