Zoológico tecnológico em projetos: o que é, causas e soluções

O que é um zoológico tecnológico em um projeto

Zoológico tecnológico é uma situação em que um projeto ou empresa usa um número excessivo de ferramentas heterogêneas resolvendo a mesma tarefa. Por exemplo, três clientes HTTP diferentes (Alamofire, OkHttp, Ktor), dois gerenciadores de estado (Redux, MobX) e três bancos de dados (Realm, CoreData, SQLite).

A diferença entre um zoológico e uma escolha deliberada de ferramentas diferentes para tarefas diferentes é a ausência de uma estratégia. Se a equipe A escolhe React Native, a equipe B escolhe Flutter, e a equipe C escolhe Kotlin Multiplatform sem uma decisão comum — isso é um zoológico. A diversidade em si não é prejudicial; sua natureza descontrolada é.

Cada novo stack em um projeto aumenta a carga cognitiva para os desenvolvedores. Para trabalhar efetivamente, é preciso lembrar as nuances de todas as tecnologias usadas. Segundo Google (2024), a alternância de contexto entre diferentes stacks reduz a produtividade do desenvolvedor em 23% em comparação com trabalhar em um ambiente tecnológico unificado.

Causas de um zoológico tecnológico

Decisões descentralizadas são a causa principal. Cada equipe escolhe tecnologias para seu projeto sem considerar a estratégia geral. A equipe de backend usa Kotlin, a equipe de ML usa Python, a equipe móvel usa Flutter. Individualmente, as decisões estão corretas, mas juntas criam um zoológico.

Fusões e Aquisições (M&A) — quando uma empresa adquire outra, os stacks tecnológicos se fundem. Dois sistemas resolvem os mesmos problemas de maneiras diferentes. Exemplo: após adquirir uma startup, uma grande empresa obtém seu stack Ruby on Rails, mesmo que o padrão interno seja Java Spring. Surge a pergunta: reescrever ou manter dois stacks em paralelo.

Mudança de tecnologias da moda — cada ciclo de hype adiciona um novo stack. Em 2015, todos escreviam em AngularJS, em 2017 — em React, em 2020 — em Svelte. Sem disciplina, um projeto acumula camadas de diferentes épocas. Módulos legados que funcionam mas não têm suporte adicionam heterogeneidade sem a capacidade de eliminá-la rapidamente.

Por que um zoológico é perigoso para a equipe e os negócios

A integração de novos desenvolvedores se torna aprender 5+ tecnologias diferentes em vez de uma. Em vez de uma semana para se familiarizar com o projeto, um novato gasta um mês dominando todas as ferramentas usadas. O tempo até a produtividade cresce proporcionalmente ao número de stacks no projeto.

Alternância de contexto — um desenvolvedor trabalhando com 3+ stacks durante o dia gasta até 30% do tempo restaurando o contexto após cada alternância. Segundo a Universidade da Califórnia (2023), após cada alternância, são necessários 23 minutos para retornar ao nível original de produtividade. Com 5 alternâncias por dia — quase 2 horas perdidas.

Riscos de segurança — cada stack requer atualizações, monitoramento de vulnerabilidades e conhecimento de melhores práticas. Uma equipe não pode ser especialista em todas as tecnologias simultaneamente. A fadiga de dependências — quando o número de bibliotecas usadas excede a capacidade da equipe de rastreá-las e atualizá-las — é uma ameaça direta à segurança do produto.

Complexidade de infraestrutura — CI/CD precisa ser configurado para cada stack. Diferentes sistemas de compilação (Gradle, CocoaPods, npm, pip), diferentes requisitos de ambiente. A equipe de infraestrutura gasta recursos mantendo pipelines heterogêneos em vez de melhorá-los.

Como diagnosticar o problema em um projeto

Inventário do stack — compile uma lista completa das tecnologias usadas: linguagens, frameworks, bancos de dados, CI/CD, sistemas de monitoramento. Para cada tecnologia, anote o número de projetos/módulos, nível de suporte e número de desenvolvedores proficientes nela em nível profissional.

Technology Radar — um método da ThoughtWorks que divide as tecnologias em 4 quadrantes: Adopt, Trial, Assess, Hold. Adopt — stacks recomendados, Trial — experimentais, Assess — em avaliação, Hold — não recomendados para uso. Exemplo: Flutter em Adopt, React Native em Hold — as equipes entendem o que escolher.

Métrica de custo de manutenção — estime quantas horas de engenharia são gastas na manutenção de cada stack por mês. Se um stack consome 10% dos recursos mas é usado em 2% dos módulos — é candidato à substituição. Um mapa de calor do stack com eixos "número de projetos" vs "complexidade de manutenção" mostra claramente as áreas problemáticas.

Métodos para padronizar o stack tecnológico

Architecture Decision Records (ADR) — documentação de decisões arquiteturais com justificativa para as escolhas tecnológicas. Cada ADR contém contexto, alternativas consideradas e argumentos para a escolha. Michael Nygard (2022) popularizou esta abordagem, e hoje ADR é um padrão para equipes que controlam a diversidade tecnológica.

Technology Review Board — um comitê de desenvolvedores líderes que aprova novas tecnologias no projeto. As decisões são tomadas com base em critérios: compatibilidade com o stack existente, suporte da comunidade, custo de migração, disponibilidade de talentos. Spotify usa um comitê semelhante desde 2018.

Portão para novos projetos — uma regra: qualquer novo serviço ou módulo usa apenas o stack aprovado. Exceções são possíveis através de ADR com justificativa. Exemplo: um novo microsserviço pode ser escrito em Kotlin apenas se a equipe provar que Java não é adequado para esta tarefa. O uso sem barreiras de qualquer tecnologia é proibido.

Redução gradual da diversidade de stacks

Fase 1: Congelamento — novos projetos em stacks não suportados são interrompidos. Uma data de fim de vida é definida para cada stack no quadrante Hold. Novas funcionalidades são escritas apenas em stacks aprovados. Módulos legados continuam funcionando mas não são estendidos.

Fase 2: Consolidação — uma ferramenta é escolhida para cada tarefa. Um cliente HTTP, um gerenciador de estado, um banco de dados. Módulos em stacks alternativos são programados para migração por prioridade. O padrão Strangler Fig é o método principal para substituição sem tempo de inatividade do sistema.

Fase 3: Migração — cada sprint, a equipe aloca 20% do tempo para reescrever módulos críticos de stacks obsoletos para os aprovados. A arquitetura alvo é documentada e não muda sem uma decisão do comitê. O processo leva de 6 a 24 meses dependendo da escala do zoológico.

Exemplo: Migração de clientes 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()
        }
    }
}