Questão de Engenharia de Software — Geral — INSTITUTO AOCP 2026

Clean Code, Refatoração e Análise Estática

Gabarito: letra B. A conduta correta diante de alta complexidade ciclomática, duplicação de código e métodos extensos é refatorar o código, aplicando o princípio da responsabilidade única (SRP) para reduzir a complexidade e eliminar as duplicações apontadas pela ferramenta de análise estática. As demais alternativas propõem mascarar o problema (A, C), abandonar a ferramenta (D) ou piorar a estrutura (E), todas contrárias aos princípios de Clean Code.

A análise estática, realizada por ferramentas como o SonarQube, tem como objetivo identificar problemas estruturais no código-fonte sem executá-lo. Ela detecta métricas como a complexidade ciclomática, que mede o número de caminhos independentes em um método, e a duplicação de código, que indica trechos repetidos que dificultam a manutenção. Quando essas métricas apontam problemas, a ação correta não é ignorar os alertas ou alterar os limites da ferramenta, mas sim tratar a causa raiz: a má estrutura do código.

A refatoração é o processo de alterar o código interno sem mudar seu comportamento externo, com o objetivo de melhorar sua qualidade. O princípio da responsabilidade única (SRP), um dos pilares do SOLID, estabelece que uma classe ou método deve ter apenas um motivo para mudar, ou seja, deve ter uma única responsabilidade. Métodos extensos com múltiplas responsabilidades violam esse princípio e são um dos principais causadores de alta complexidade ciclomática. Ao refatorar, quebrando métodos extensos em métodos menores e mais coesos, a complexidade ciclomática tende a diminuir, pois cada novo método terá menos caminhos independentes. Da mesma forma, a extração de trechos duplicados para métodos ou classes reutilizáveis elimina a duplicação de código.

A alternativa B é a única que propõe uma ação que ataca diretamente os problemas identificados, alinhada aos princípios de Clean Code e às boas práticas de engenharia de software. As demais alternativas representam anti-padrões: aumentar o limite de complexidade no SonarQube (A) apenas esconde o problema, desabilitar regras de duplicação (C) é uma fuga da responsabilidade, substituir análise estática por testes manuais (D) é um equívoco, pois são atividades complementares, e concentrar validações em um método utilitário estático (E) piora a coesão e aumenta o acoplamento.

A pegadinha desta questão está em alternativas que parecem "resolver" o problema de forma pragmática, mas que na verdade são anti-padrões. O candidato deve reconhecer que a análise estática é uma ferramenta de apoio à qualidade, e não um obstáculo a ser contornado. A resposta correta é aquela que propõe a melhoria da estrutura do código, mesmo que isso demande mais trabalho inicial.

Alternativa A — ❌ Incorreta

Aumentar o limite aceitável de complexidade ciclomática no SonarQube é uma ação que mascara o problema em vez de resolvê-lo. A ferramenta está corretamente alertando sobre a alta complexidade, que é um indicador de código difícil de testar e manter. Alterar o limite apenas silencia o alerta, mas não melhora a qualidade do código. A conduta correta é refatorar o código para reduzir a complexidade, não ajustar a régua de medição.

Alternativa B — ✅ Correta ⟵ GABARITO

Esta alternativa propõe a ação correta: refatorar os métodos extensos, aplicando o princípio da responsabilidade única. Isso reduz a complexidade ciclomática, pois métodos menores e mais coesos têm menos caminhos independentes, e elimina trechos duplicados, que podem ser extraídos para métodos ou classes reutilizáveis. Essa é a conduta alinhada aos princípios de Clean Code e às práticas de análise estática, que visam melhorar a qualidade do código.

Alternativa C — ❌ Incorreta

Desabilitar temporariamente as regras de duplicação de código no SonarQube é outra forma de mascarar o problema. A duplicação de código é um indicador de má qualidade, pois aumenta o esforço de manutenção e o risco de inconsistências. Desabilitar a regra não elimina a duplicação; apenas esconde o alerta. A conduta correta é refatorar o código para eliminar as duplicações, não desligar a ferramenta.

Alternativa D — ❌ Incorreta

Substituir a análise estática por testes manuais exploratórios é um equívoco, pois são atividades complementares, não excludentes. A análise estática identifica problemas estruturais no código, como complexidade e duplicação, enquanto os testes manuais exploratórios verificam o comportamento do sistema. Um não substitui o outro. A análise estática é mais eficaz para identificar problemas estruturais, pois pode analisar todo o código de forma sistemática, enquanto os testes manuais são limitados pela capacidade humana de explorar todos os cenários.

Alternativa E — ❌ Incorreta

Concentrar as regras de validação em um único método utilitário estático é uma má prática que piora a estrutura do código. Isso cria um método "god object" ou "god method", que concentra muitas responsabilidades, aumentando a complexidade ciclomática e o acoplamento. Além disso, não reduz o número de arquivos analisados pela ferramenta, pois a análise estática analisa todo o código-fonte, independentemente de onde as regras estão concentradas. A conduta correta é distribuir as responsabilidades de forma coesa, não concentrá-las em um único ponto.

Gabarito: letra B