Código lixo e bagunça em projetos móveis — sinais e refatoração

O que é código lixo no desenvolvimento

Código lixo (também spaghetti code, bagunça, big ball of mud) é uma metáfora para uma base de código que perdeu sua estrutura e se transformou em uma teia emaranhada de dependências. Nesse código, qualquer alteração em um lugar quebra outro, e adicionar nova funcionalidade se torna uma aventura arriscada.

No desenvolvimento móvel, o código lixo é especialmente crítico: um aplicativo construído sobre uma “bagunça” começa a ficar lento, travar em dispositivos antigos e luta para passar pela revisão de código. Um projeto iOS sem arquitetura pode não passar na revisão da App Store devido à instabilidade.

De acordo com a Stripe, os desenvolvedores gastam até 42% do seu tempo de trabalho lendo e entendendo código existente. Em projetos com código lixo, esse número ultrapassa 60%, tornando o desenvolvimento extremamente ineficiente.

Origem dos termos

Spaghetti code é o termo mais antigo, datado da década de 1970. Ele descreve código com fluxo de controle caótico, lembrando espaguete emaranhado.

Big ball of mud é um termo introduzido por Brian Foote e Joseph Yoder em 1997 para descrever sistemas sem uma arquitetura clara que crescem caoticamente.

Por que o código lixo é perigoso para os negócios

O código lixo retarda o lançamento de novos recursos no mercado. A equipe gasta tempo não criando valor, mas tentando entender como o código existente funciona e como não quebrar nada.

De acordo com a McKinsey, empresas com baixa qualidade de código gastam 20-40% mais na manutenção do produto, e a velocidade de lançamento de novos recursos é 2 a 3 vezes menor em comparação com empresas de alta qualidade de código.

Sinais de código lixo e como reconhecê-lo

Reconhecer o código lixo pode ser feito através de um conjunto de indicadores objetivos, alguns dos quais são medidos automaticamente. Quanto mais indicadores coincidirem, mais grave é o problema.

Na indústria, métricas de qualidade de código como Complexidade de Halstead, Índice de Manutenibilidade e Taxa de Dívida Técnica são usadas. Conhecer essas métricas ajuda a avaliar objetivamente o estado de uma base de código.

Copia e cola (duplicação de código)

O sinal mais comum de código lixo são blocos de código repetidos. Em vez de extrair uma função comum, os desenvolvedores copiam código de um lugar para outro com mínimas alterações.

Um nível de duplicação de até 5% é considerado normal. Se a duplicação exceder 15%, é um sinal grave. Ferramentas como Simian e PMD Copy Paste Detector ajudam a identificar cópias automaticamente.

Métodos e classes longos

Um método com mais de 100 linhas é um sinal claro de código lixo. Esse método geralmente faz demais e viola o Princípio da Responsabilidade Única.

Classes com mais de 1000 linhas de código também são problemáticas. Elas contêm funcionalidades não relacionadas, dificultando testes, compreensão e modificação do código.

Alta complexidade ciclomática

A complexidade ciclomática de McCabe é uma métrica que mostra o número de caminhos independentes no código. Um valor acima de 15 é considerado problemático.

Métodos com complexidade acima de 30 estão na “zona de desastre.” Eles contêm muitas ramificações, tornando impossível testá-los e entendê-los sem uma análise profunda.

Causas do código lixo

O código lixo não aparece “por si só” — é sempre o resultado de certos processos e decisões na equipe. Entender as causas ajuda a preveni-lo no futuro.

De acordo com o JetBrains Developer Ecosystem 2024, 67% dos desenvolvedores admitem que escrevem código pior do que poderiam devido à falta de tempo. Esta é a principal razão para o acúmulo de dívida técnica.

Pressa e prazos

A causa mais comum são prazos apertados. A equipe escreve código “como sair”, só para cumprir o prazo. Refatoração, testes e revisão de código são adiados “para depois.”

O problema é que “depois” nunca chega — novos prazos aparecem no próximo sprint, e a dívida técnica se acumula como uma bola de neve.

Falta de revisão de código

Sem revisão de código, cada desenvolvedor escreve em seu próprio estilo, usa seus próprios padrões e deixa suas próprias “marcas.” Com o tempo, a base de código perde uniformidade.

Equipes que praticam revisão de código obrigatória para cada pull request têm 60% menos defeitos em produção, de acordo com um estudo da SmartBear 2024.

Arquitetura fraca desde o início

Se um projeto começa sem uma arquitetura clara, o código lixo é inevitável. As primeiras “soluções rápidas” estabelecem uma base sobre a qual é difícil construir algo de qualidade depois.

No desenvolvimento móvel, a escolha da arquitetura (MVC, MVP, MVVM, Clean Architecture) deve ser uma decisão consciente tomada antes de começar a escrever código, não um resultado da evolução.

Métodos para combater o código lixo

Combater o código lixo requer uma abordagem sistemática e disciplina de toda a equipe. Não existe uma única ferramenta ou prática que resolva o problema — é necessário um conjunto de medidas.

O princípio principal é evitar o código lixo na etapa de escrita, não corrigi-lo depois. A prevenção é sempre mais barata do que refatorar uma “bagunça” existente.

Padrões de codificação

Um estilo de código unificado é a base para prevenir o código lixo. Os padrões de codificação (Code Style) devem ser documentados e verificados automaticamente por linters.

Para iOS usa-se SwiftLint, para Android, Ktlint e Detekt. Configurar regras em um arquivo de configuração permite rejeitar automaticamente pull requests que violem os padrões.

Refatoração regular

A refatoração não é corrigir bugs, mas melhorar a estrutura do código sem alterar seu comportamento. Deve ser uma parte regular do processo de desenvolvimento, não um projeto separado.

Recomenda-se dedicar 20% do tempo de cada sprint à refatoração e ao pagamento da dívida técnica. Isso evita o acúmulo de “bagunça” e mantém a velocidade da equipe a longo prazo.

Revisão de código obrigatória

Cada pull request deve ser revisado por pelo menos um desenvolvedor. A revisão de código identifica não apenas bugs, mas também violações de arquitetura, problemas de estilo e potenciais fontes de código lixo.

Uma boa prática é uma lista de verificação para revisão de código que inclua verificação de cópias, comprimento de métodos, complexidade ciclomática e cobertura de testes. Sem uma lista de verificação, os revisores perdem até 50% dos problemas.

Ferramentas para limpar a base de código

Ferramentas modernas de análise de código permitem detectar automaticamente o código lixo, medir a dívida técnica e monitorar a qualidade. Integrar essas ferramentas no pipeline de CI/CD fornece monitoramento contínuo.

Recomenda-se usar pelo menos um analisador estático e uma ferramenta de medição de métricas. Adicionalmente, uma plataforma para agregar dados de qualidade de código pode ser conectada.

Analisadores estáticos

• SonarQube — a plataforma líder de análise de qualidade de código, suporta mais de 30 linguagens e fornece métricas de Taxa de Dívida Técnica
• ESLint — o padrão para JavaScript e TypeScript, configurável através de arquivos de configuração e integrado em IDEs
• SwiftLint — uma ferramenta obrigatória para projetos iOS, verifica a conformidade com o Guia de Estilo Swift

De acordo com a SonarSource, equipes que usam análise estática reduzem o número de bugs em produção em 30% já no primeiro trimestre após a adoção.

Ferramentas de medição de métricas

CodeClimate e Codacy são plataformas que agregam métricas de qualidade de código, rastreiam tendências e mostram os “pontos quentes” — arquivos com maior dívida técnica.

Para projetos Android, o Detekt fornece mais de 100 regras de análise integradas, incluindo verificações de complexidade ciclomática, comprimento de métodos e duplicação de código.