Duplicação de código custa menos que a abstração errada, diz Sandi Metz

Em 20 de janeiro de 2016, a influente programadora e educadora norte-americana Sandi Metz publicou em seu blog pessoal um ensaio técnico que reacendeu uma das discussões mais duradouras da engenharia de software moderna. Intitulado "The wrong abstraction", o texto resgatava e aprofundava reflexões originalmente distribuídas em seu informativo digital, o Chainline Newsletter, sobre os perigos ocultos de se criar estruturas de código excessivamente complexas. A semente dessa discussão havia sido plantada publicamente cerca de dois anos antes, durante sua aclamada apresentação na conferência RailsConf 2014, intitulada "all the little things", na qual Metz desafiou o dogma do desenvolvimento de software ao afirmar que a duplicação é incomensuravelmente mais barata do que a abstração errada.

O impacto dessa apresentação de Sandi Metz na RailsConf 2014 gerou ondas de choque imediatas na comunidade global de desenvolvedores de software, dividindo opiniões e provocando reações intensas. Enquanto alguns profissionais do setor sugeriram publicamente que a palestrante havia perdido a sanidade ao questionar o princípio clássico do DRY (Don't Repeat Yourself), uma expressiva parcela da comunidade técnica celebrou a declaração como uma libertação pragmática. Um exemplo notável dessa reação entusiasmada ocorreu em 7 de março de 2014, quando o usuário @pims publicou no Twitter uma captura de tela do slide da apresentação de Metz com a legenda "This, a million times this!", marcando os perfis @sandimetz, @rbonales e @BonzoESC para endossar a máxima de que a duplicação deve ser preferida em detrimento de uma abstração equivocada.

Origem do conceito

No ecossistema de tecnologia brasileiro, onde as equipes frequentemente lidam com sistemas legados em rápida expansão, a tese apresentada na RailsConf 2014 serve como um guia de sobrevivência contra a complexidade acidental. A análise estrutural proposta por Sandi Metz descreve um ciclo destrutivo de oito etapas que se inicia de forma bem-intencionada quando o Programador A identifica uma duplicação trivial no código-fonte e decide agir para eliminá-la.

O ciclo nocivo mapeado por Sandi Metz avança quando este Programador A extrai a duplicação, nomeia o novo elemento — que pode se tornar um novo método ou até mesmo uma nova classe — e substitui o código duplicado por essa nova abstração. Satisfeito com o que considera um código perfeito, o desenvolvedor conclui a tarefa, mas deixa uma armadilha armada para os próximos profissionais que assumirem a manutenção do repositório.

O ciclo da abstração incorreta

A engenheira explica que o declínio técnico começa de verdade quando surge um novo requisito de negócio para o qual a abstração criada pelo Programador A se mostra "quase perfeita". Sob a pressão de prazos reais, o Programador B assume a tarefa e, sentindo-se moralmente obrigado a preservar a abstração existente, altera o código original para aceitar um novo parâmetro e adiciona uma condicional para adaptar o comportamento.

O processo de degradação se repete de forma contínua até o colapso do sistema, culminando na chegada do Programador X, que adiciona mais parâmetros e novas ramificações condicionais à mesma estrutura. O resultado final descrito por Sandi Metz é um loop de remendos técnicos que torna o código completamente incompreensível, deixando o desenvolvedor seguinte em uma situação de extrema dificuldade operacional.

A armadilha psicológica do código

Em seu diagnóstico técnico de 2016, Sandi Metz faz uma incursão profunda na psicologia do desenvolvimento de software ao associar a relutância em descartar abstrações ruins ao viés conhecido como sunk cost fallacy (a falácia dos custos irrecuperáveis). A autora argumenta que o código existente exerce uma influência psicológica extremamente poderosa sobre os desenvolvedores, funcionando como uma evidência tácita de que sua presença na aplicação é correta, necessária e valiosa. Existe uma tendência subconsciente de associar a complexidade de um trecho de código ao esforço despendido para sua concepção, gerando uma pressão invisível para que o trabalho anterior seja preservado a qualquer custo pelas equipes técnicas.

"Goodness, that's so confusing, it must have taken ages to get right. Surely it's really, really important. It would be a sin to let all that effort go to waste."

Essa barreira psicológica descrita por Sandi Metz impede que os programadores tomem a decisão técnica mais racional ao herdarem um sistema repleto de condicionais. Em vez de reavaliar o design original, os desenvolvedores sentem-se pressionados a dar continuidade ao modelo quebrado, empurrando modificações forçadas em uma estrutura que perdeu totalmente sua função de abstração coerente. Conforme detalhado no ensaio publicado no blog de Metz em 2016, o código passa de uma representação elegante de um conceito de negócios para um procedimento altamente frágil, difícil de compreender, fácil de quebrar e que entrelaça ideias apenas vagamente associadas entre si.

Como reverter o erro técnico

Para escapar desse círculo vicioso de manutenções dolorosas, Sandi Metz propõe um plano de ação objetivo focado no retrocesso arquitetônico como a rota mais eficiente para o progresso do projeto. O primeiro passo desse método consiste em reintroduzir deliberadamente a duplicação de código por meio do processo de inlining, que consiste em pegar o código da abstração e colá-lo de volta diretamente em cada um dos pontos de chamada do sistema. Essa abordagem elimina a falsa centralização criada no passado e isola as implementações em seus respectivos contextos de execução, pavimentando o caminho para um diagnóstico mais claro.

Uma vez que o código outrora unificado esteja novamente distribuído, o desenvolvedor deve analisar individualmente cada ponto de chamada para avaliar quais parâmetros e condicionais são de fato necessários para aquela execução específica. Sandi Metz orienta que as equipes excluam sumariamente todas as ramificações de código e condicionais que não se aplicam ao contexto do invocador em questão, reduzindo o escopo de cada ponto de chamada estritamente ao que ele precisa executar. Ao desfazer as decisões de design anteriores dessa maneira sistemática, os engenheiros frequentemente constatam que as execuções eram significativamente únicas e que a suposta abstração comum nunca existiu de fato.

Após a remoção completa da antiga abstração equivocada e a consolidação de códigos independentes e duplicados, a equipe ganha uma folha em branco para iniciar o processo de design novamente de forma limpa. A partir dessa nova perspectiva, os desenvolvedores podem observar a evolução real dos requisitos de negócios e, se oportuno, isolar novas duplicações e extrair abstrações legítimas com base em dados concretos, em vez de suposições apressadas. Sandi Metz enfatiza que esse recuo técnico não representa uma derrota ou um retrocesso para o time de desenvolvimento, mas sim uma manobra tática essencial para avançar na direção de uma arquitetura de software muito mais sustentável e robusta.

Estudo de caso de eficácia

A eficácia prática de reintroduzir a duplicação em sistemas altamente complexos foi testemunhada por Sandi Metz em diversos cenários reais de consultoria e mentoria de engenharia de software ao longo de sua carreira. A autora relata ter acompanhado equipes que tentavam avançar obstinadamente com abstrações incorretas, sofrendo de forma brutal para implementar funcionalidades simples devido ao emaranhado de parâmetros acumulados. Cada nova funcionalidade entregue por esses times complicava ainda mais a base de código, criando um gargalo técnico que tornava as entregas subsequentes exponencialmente mais difíceis, lentas e propensas a falhas graves em produção.

Tudo mudou quando esses times de engenharia alteraram sua postura mental, abandonando a obsessão em preservar o investimento de tempo feito no código antigo e aceitando que a abstração original, embora tenha feito sentido em algum momento do passado, já não servia para as necessidades atuais do negócio. Ao se permitirem repensar o design em conformidade com as demandas reais e aplicarem a técnica de inlining recomendada por Sandi Metz, o caminho técnico a ser seguido tornou-se imediatamente evidente para todos os envolvidos. O processo de desenvolvimento recuperou sua velocidade natural, permitindo que a adição de novas funcionalidades ocorresse de forma muito mais rápida, simples e com menor atrito operacional.

O ecossistema de livros técnicos

Como complemento prático às lições de design apresentadas em seu blog de 2016, Sandi Metz promoveu o lançamento da aguardada segunda edição de seu aclamado livro técnico, 99 Bottles of OOP. Esta nova edição da obra de engenharia de software foi expandida de forma significativa, recebendo três capítulos inéditos criados para cobrir lacunas de arquitetura e tornando o volume total do livro aproximadamente 50% mais extenso do que a primeira versão do manual. O foco principal da publicação está no ensino prático de design orientado a objetos em um nível conceitual, transcendendo as particularidades de sintaxe de plataformas específicas.

Para garantir que o conteúdo fosse de utilidade direta para diferentes comunidades de tecnologia, o livro 99 Bottles of OOP foi disponibilizado em edições tecnicamente idênticas, mas que utilizam linguagens de programação distintas em seus exemplos de código: Ruby, JavaScript e PHP. A distribuição comercial do ecossistema literário de Metz apresenta uma estrutura singular que combina essas três vertentes linguísticas com variações temáticas focadas em bebidas de cerveja (beer) e leite (milk). Os leitores podem adquirir os volumes em formatos digitais amplamente difundidos de mercado, incluindo arquivos nos formatos epub, kepub, mobi e pdf.

Essa matriz de distribuição projetada por Sandi Metz gera um portfólio de 24 downloads possíveis de arquivos únicos, mas que preservam rigorosamente a mesma essência de conteúdo educacional sobre desenvolvimento de software. A política comercial adotada para a segunda edição garante que a realização de uma única compra confira ao desenvolvedor o direito de realizar o download de todas as variações linguísticas, temáticas e de formatos de arquivo disponíveis em sua plataforma. Ao oferecer essa flexibilidade extrema, Metz reforça de forma prática a filosofia de que o bom design orientado a objetos é um conhecimento universal, que permanece idêntico e valioso independentemente da linguagem de programação de escolha do desenvolvedor.

Relevância no mercado brasileiro

O debate técnico estimulado por Sandi Metz e as diretrizes detalhadas em 99 Bottles of OOP possuem imensa relevância prática para o ecossistema de startups e empresas de tecnologia no Brasil. Em um cenário caracterizado por restrições severas de orçamento de engenharia, escassez de profissionais de desenvolvimento sêniores e a necessidade constante de pivotar modelos de negócios para sobreviver, o acúmulo de débito técnico decorrente de abstrações precoces e incorretas é um dos principais fatores de mortalidade de projetos digitais. A máxima consagrada por Metz na RailsConf 2014 oferece uma alternativa viável para que equipes brasileiras mantenham a agilidade operacional sem se afogarem em complexidade desnecessária.

Ao adotarem a duplicação temporária como uma ferramenta de aprendizado arquitetônico antes de consolidar uma abstração definitiva, os times de engenharia de software no Brasil conseguem mitigar os riscos associados à pressa do desenvolvimento ágil. Conforme preconiza o ensaio de 2016, a pressa em eliminar a duplicação a qualquer custo frequentemente gera um monstro arquitetônico que exige manutenções caríssimas e paralisa a inovação do produto. A lição de Sandi Metz de que o caminho mais rápido para frente às vezes exige dar um passo atrás serve como um lembrete valioso de que o pragmatismo e a simplicidade técnica continuam sendo os ativos mais valiosos para qualquer equipe que pretenda construir softwares duradouros e escaláveis.