Zoo tecnologico nei progetti: cos'è, cause e soluzioni

Cos'è uno zoo tecnologico in un progetto

Zoo tecnologico è una situazione in cui un progetto o un'azienda utilizza un numero eccessivo di strumenti eterogenei che risolvono lo stesso compito. Ad esempio, tre diversi client HTTP (Alamofire, OkHttp, Ktor), due gestori di stato (Redux, MobX) e tre database (Realm, CoreData, SQLite).

La differenza tra uno zoo e una scelta consapevole di strumenti diversi per compiti diversi è l'assenza di una strategia. Se il team A sceglie React Native, il team B sceglie Flutter e il team C sceglie Kotlin Multiplatform senza una decisione comune — questo è uno zoo. La diversità in sé non è dannosa; è la sua natura incontrollata a esserlo.

Ogni nuovo stack in un progetto aumenta il carico cognitivo per gli sviluppatori. Per lavorare efficacemente, bisogna ricordare le sfumature di tutte le tecnologie utilizzate. Secondo Google (2024), il cambio di contesto tra diversi stack riduce la produttività dello sviluppatore del 23% rispetto al lavoro in un ambiente tecnologico unificato.

Cause di uno zoo tecnologico

Decisioni decentralizzate sono la causa principale. Ogni team sceglie le tecnologie per il proprio progetto senza considerare la strategia complessiva. Il team backend usa Kotlin, il team ML usa Python, il team mobile usa Flutter. Individualmente, le decisioni sono corrette, ma insieme creano uno zoo.

Fusioni e Acquisizioni (M&A) — quando un'azienda ne acquisisce un'altra, gli stack tecnologici si fondono. Due sistemi risolvono gli stessi problemi in modi diversi. Esempio: dopo l'acquisizione di una startup, una grande azienda ottiene il suo stack Ruby on Rails, anche se lo standard interno è Java Spring. Sorge la domanda: riscrivere o mantenere due stack in parallelo.

Cambiamento di tecnologie di tendenza — ogni ciclo di hype aggiunge un nuovo stack. Nel 2015, tutti scrivevano in AngularJS, nel 2017 — in React, nel 2020 — in Svelte. Senza disciplina, un progetto accumula strati di epoche diverse. I moduli legacy che funzionano ma non sono supportati aggiungono eterogeneità senza possibilità di eliminarla rapidamente.

Perché uno zoo è pericoloso per il team e il business

L'onboarding di nuovi sviluppatori diventa l'apprendimento di 5+ tecnologie diverse invece di una. Invece di una settimana per immergersi nel progetto, un nuovo arrivato impiega un mese per padroneggiare tutti gli strumenti utilizzati. Il tempo per la produttività cresce proporzionalmente al numero di stack nel progetto.

Cambio di contesto — uno sviluppatore che lavora con 3+ stack durante la giornata spende fino al 30% del tempo per ripristinare il contesto dopo ogni cambio. Secondo l'Università della California (2023), dopo ogni cambio, sono necessari 23 minuti per tornare al livello di produttività originale. Con 5 cambi al giorno — quasi 2 ore perse.

Rischi di sicurezza — ogni stack richiede aggiornamenti, monitoraggio delle vulnerabilità e conoscenza delle best practice. Un team non può essere esperto in tutte le tecnologie contemporaneamente. L'affaticamento delle dipendenze — quando il numero di librerie utilizzate supera la capacità del team di tracciarle e aggiornarle — è una minaccia diretta alla sicurezza del prodotto.

Complessità dell'infrastruttura — CI/CD deve essere configurato per ogni stack. Diversi sistemi di build (Gradle, CocoaPods, npm, pip), diversi requisiti ambientali. Il team di infrastruttura spende risorse per mantenere pipeline eterogenee invece di migliorarle.

Come diagnosticare il problema in un progetto

Inventario dello stack — compila un elenco completo delle tecnologie utilizzate: linguaggi, framework, database, CI/CD, sistemi di monitoraggio. Per ogni tecnologia, annota il numero di progetti/moduli, il livello di supporto e il numero di sviluppatori competenti a livello professionale.

Technology Radar — un metodo di ThoughtWorks che divide le tecnologie in 4 quadranti: Adopt, Trial, Assess, Hold. Adopt — stack raccomandati, Trial — sperimentali, Assess — in valutazione, Hold — non raccomandati per l'uso. Esempio: Flutter in Adopt, React Native in Hold — i team capiscono cosa scegliere.

Metrica del costo di manutenzione — stima quante ore di ingegneria vengono spese per la manutenzione di ogni stack al mese. Se uno stack consuma il 10% delle risorse ma viene utilizzato nel 2% dei moduli — è candidato alla sostituzione. Una mappa di calore dello stack con gli assi "numero di progetti" vs "complessità di manutenzione" mostra chiaramente le aree problematiche.

Metodi per standardizzare lo stack tecnologico

Architecture Decision Records (ADR) — documentazione delle decisioni architetturali con giustificazione delle scelte tecnologiche. Ogni ADR contiene contesto, alternative considerate e argomenti a favore della scelta. Michael Nygard (2022) ha reso popolare questo approccio, e oggi ADR è uno standard per i team che controllano la diversità tecnologica.

Technology Review Board — un comitato di sviluppatori leader che approva le nuove tecnologie nel progetto. Le decisioni vengono prese sulla base di criteri: compatibilità con lo stack esistente, supporto della comunità, costo di migrazione, disponibilità di talenti. Spotify utilizza un comitato simile dal 2018.

Gateway per nuovi progetti — una regola: qualsiasi nuovo servizio o modulo utilizza solo lo stack approvato. Le eccezioni sono possibili tramite ADR con giustificazione. Esempio: un nuovo microservizio può essere scritto in Kotlin solo se il team dimostra che Java non è adatto a questo compito. L'uso senza barriere di qualsiasi tecnologia è vietato.

Riduzione graduale della diversità degli stack

Fase 1: Congelamento — i nuovi progetti su stack non supportati vengono fermati. Viene stabilita una data di fine vita per ogni stack nel quadrante Hold. Le nuove funzionalità vengono scritte solo su stack approvati. I moduli legacy continuano a funzionare ma non vengono estesi.

Fase 2: Consolidamento — viene scelto uno strumento per ogni compito. Un client HTTP, un gestore di stato, un database. I moduli su stack alternativi vengono programmati per la migrazione per priorità. Il modello Strangler Fig è il metodo principale per la sostituzione senza tempi di inattività del sistema.

Fase 3: Migrazione — ogni sprint, il team alloca il 20% del tempo per riscrivere i moduli critici da stack obsoleti a quelli approvati. L'architettura target viene documentata e non cambia senza una decisione del comitato. Il processo richiede da 6 a 24 mesi a seconda della scala dello zoo.

Esempio: Migrazione di client HTTP

// 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()
        }
    }
}