Teknologisk djurpark i projekt: vad det är, orsaker och metoder

Vad är en teknologisk djurpark i ett projekt

Teknologisk djurpark — en situation där ett eller flera företag använder ett överdrivet antal olika verktyg för att lösa samma uppgift. Till exempel tre olika HTTP-klienter (Alamofire, OkHttp, Ktor), två tillståndshanterare (Redux, MobX) och tre databaser (Realm, CoreData, SQLite).

Skillnaden mellan en djurpark och ett medvetet val av olika verktyg för olika uppgifter är avsaknaden av strategi. Om team A väljer React Native, team B — Flutter och team C — Kotlin Multiplatform utan gemensamt beslut — är detta en djurpark. Mångfald i sig är inte skadlig, det skadliga är bristen på kontroll.

Varje ny stack i projektet ökar kognitiv belastning för utvecklare. För att arbeta effektivt måste de komma ihåg nyanserna i alla använda teknologier. Enligt Google (2024) minskar kontextbyte mellan olika stackar utvecklarens produktivitet med 23% jämfört med arbete i en enhetlig teknologisk miljö.

Orsaker till uppkomsten av teknologisk djurpark

Decentraliserade beslut — den främsta orsaken. Varje team väljer teknologier för sitt eget projekt utan hänsyn till den övergripande strategin. Backendteamet använder Kotlin, ML-teamet — Python, mobilteamet — Flutter. Var för sig är besluten korrekta, men tillsammans skapar de en djurpark.

Fusioner och förvärv — när ett företag förvärvar ett annat slås teknikstackar samman. Två system löser samma uppgifter på olika sätt. Exempel: efter förvärv av en startup får det stora företaget dess stack på Ruby on Rails, trots att den interna standarden är Java Spring. Frågan uppstår: skriva om eller underhålla två stackar parallellt.

Förändring av trendiga teknologier — varje hype-cykel lägger till en ny stack. 2015 skrev alla i AngularJS, 2017 — i React, 2020 — i Svelte. Utan disciplin samlar projektet lager från olika epoker. Legacymoduler som fungerar men inte underhålls lägger till mångfald utan möjlighet till snabb eliminering.

Varför djurparken är farlig för teamet och verksamheten

Introduktion av nya utvecklare blir att lära sig 5+ olika teknologier istället för en. Istället för en vecka att bekanta sig med projektet spenderar nybörjaren en månad på att bemästra alla använda verktyg. Tid att uppnå produktivitet ökar proportionellt mot antalet stackar i projektet.

Kontextbyte — en utvecklare som arbetar med 3+ stackar under dagen förlorar upp till 30% av tiden på att återställa kontexten efter varje byte. Enligt University of California (2023) krävs 23 minuter efter varje byte för att återgå till den ursprungliga produktivitetsnivån. Vid 5 byten per dag — nästan 2 timmar förlorade.

Säkerhetsrisker — varje stack kräver uppdateringar, övervakning av sårbarheter och kunskap om bästa praxis. Ett team kan inte vara expert på alla teknologier samtidigt. Beroendetrötthet — när antalet använda bibliotek överstiger teamets förmåga att spåra och uppdatera dem — är ett direkt hot mot produktsäkerheten.

Infrastrukturkomplexitet — CI/CD måste konfigureras för varje stack. Olika byggsystem (Gradle, CocoaPods, npm, pip), olika miljökrav. Infrastrukturteamet lägger resurser på att underhålla olika pipelines istället för att förbättra dem.

Hur man diagnostiserar problemet i ett projekt

Stackinventering — upprätta en fullständig lista över använda teknologier: språk, ramverk, databaser, CI/CD, övervakningssystem. För varje teknologi, notera antalet projekt/moduler, supportnivå och antalet utvecklare som behärskar den på professionell nivå.

Technology Radar — ThoughtWorks metod som delar in teknologier i 4 kvadranter: Adopt, Trial, Assess, Hold. Adopt — rekommenderade stackar, Trial — experimentella, Assess — under utvärdering, Hold — rekommenderas inte för användning. Exempel: Flutter i Adopt, React Native i Hold — teamen vet vad de ska välja.

Underhållskostnadsmetrik — uppskatta hur många ingenjörstimmar per månad som läggs på underhåll av varje stack. Om en stack förbrukar 10% av resurserna men används i 2% av modulerna — är den en kandidat för utbyte. Stackens värmekarta: axlarna ”antal projekt” vs ”underhållskomplexitet” visar problemområden.

Metoder för standardisering av teknikstack

Arkitekturbeslutsposter (ADR) — dokumentering av arkitekturbeslut med motivering av teknikval. Varje ADR innehåller kontext, övervägda alternativ och argument för valet. Michael Nygard (2022) populariserade detta tillvägagångssätt och idag är ADR en standard för team som kontrollerar teknologisk mångfald.

Teknikgranskningskommitté — en kommission av seniora utvecklare som godkänner nya teknologier i projektet. Beslut fattas baserat på kriterier: kompatibilitet med befintlig stack, communitysupport, migrationskostnad, tillgång på talang. Spotify har använt en liknande kommitté sedan 2018.

Grind för nya projekt — regel: varje ny tjänst eller modul använder endast godkänd stack. Undantag är möjliga via ADR med motivering. Exempel: en ny mikrotjänst kan skrivas i Kotlin endast om teamet bevisar att Java inte är lämpligt för denna uppgift. Obegränsad användning av vilka teknologier som helst är förbjuden.

Stegvis minskning av stackmångfald

Fas 1: Frysning — nya projekt på ostödda stackar stoppas. För varje stack i Hold-kvadranten fastställs ett slutdatum. Ny funktionalitet skrivs endast på godkända stackar. Legacymoduler fortsätter att fungera men utvecklas inte.

Fas 2: Konsolidering — för varje uppgift väljs ett verktyg. En HTTP-klient, en tillståndshanterare, en databas. Moduler på alternativa stackar planeras för migrering efter prioritet. Strangler Fig-mönstret — den främsta metoden för utbyte utan att stoppa systemet.

Fas 3: Migrering — varje sprint avsätter teamet 20% av tiden för att skriva om kritiska moduler från föråldrade stackar till godkända. Målarkitektur fastställs i ett dokument och ändras inte utan kommitténs beslut. Processen tar 6 till 24 månader beroende på djurparkens storlek.

Exempel: migrering av HTTP-klienter

// Före: 3 olika HTTP-klienter i ett projekt
class HttpClientResolver {
    def resolve(moduleName) {
        switch(moduleName) {
            case "payments": return new OkHttpClient()
            case "chat": return new KtorClient()
            case "analytics": return new RetrofitClient()
        }
    }
}