Examinar as características de condicionais complexas

  • 8 minutos

Os desenvolvedores não têm a intenção de escrever um emaranhado complicado de instruções if do zero. Em vez disso, as condicionais complexas se acumulam gradualmente à medida que uma base de código evolui. Entender esse processo evolutivo pode ajudá-lo a identificar esses padrões em seus próprios projetos (e, idealmente, impedi-los antecipadamente).

Como as condicionais complexas surgem

Condicionales complexas geralmente surgem de uma combinação de fatores:

  • Adições de recursos incrementais: o código geralmente começa com uma estrutura de decisão simples para um cenário simples. Com o tempo, novos recursos ou requisitos são adicionados. Cada vez, em vez de reprojetar a lógica, um desenvolvedor pode escolher o caminho de menor resistência: basta adicionar outra if ou estender a condicional existente. Por exemplo, uma rotina de processamento de pedidos pode começar verificando if (order.Total > 100) { applyDiscount(); }. Mais tarde, um desconto especial para os clientes VIP é adicionado como outra condição, em seguida, uma promoção de férias é adicionada como uma condição aninhada dentro do desconto VIP, e assim por diante. Cada mudança individual parece pequena, mas elas se compõem em uma complexa rede de condições.

  • Correções de bug de caso de borda: outra fonte comum são patches rápidos para bugs. Suponha que uma revisão de garantia de qualidade gere um tíquete que descreve o seguinte problema: "se a conta do usuário estiver bloqueada e tentar executar uma redefinição de senha, o sistema se comportará incorretamente". Um desenvolvedor pode resolver esse problema inserindo uma verificação condicional direcionada no código. Por exemplo, código que implementa a seguinte lógica: "se accountLocked e passwordReset, então faça X". Essa correção funciona e o código passa nos testes associados. No entanto, ele adiciona outra ramificação à lógica. Ao longo da vida útil do projeto, muitas dessas correções de maiúsculas e minúsculas podem ser empilhadas, cada uma adicionando um pouco mais de aninhamento ou complexidade. O que começou como um simples if/else pode se transformar em uma árvore com várias ramificações, pois casos especiais são acrescentados sem refatoração.

  • Requisitos em evolução: os requisitos geralmente crescem além do design original do código. Considere um sistema de aprovação de empréstimos que toma uma decisão inicial verificando algumas métricas básicas (pontuação de crédito e renda). À medida que o negócio se expande, eles introduzem mais regras: tratamento especial para tomadores de empréstimo iniciantes, aprovação condicional com garantia, diferentes regras para vários tipos de empréstimo, verificações regulatórias, etc. Se o código original não for reestruturado, a inclinação natural será aninhar mais instruções if. Por exemplo, dentro do if (creditOK) bloco, adicione if (hasCollateral) ... else ...e dentro desse bloco, talvez outro if para um sinalizador regulatório. Cada nova regra aumenta o aninhamento ou adiciona novos branches no mesmo nível. Ao longo de meses ou anos, a função de aprovação do empréstimo se transforma em um método gigante que tem centenas de linhas de comprimento, com um emaranhado de condições cobrindo todos os cenários encontrados pela empresa.

  • Falta de refatoração periódica: problemas de complexidade de código são desenvolvidos quando ocorrem adições incrementais sem revisões que limpam a estrutura de código. É comum no desenvolvimento rápido despriorizar a refatoração ("funciona, não vamos tocá-la"). Como resultado, a lógica condicional que deve ser reprojetada (dividida em funções menores ou transformada em uma tabela de configuração etc.) permanece em uma forma cada vez mais desajeitada. Quando alguém percebe o quão desordeiro é o código, a função é tão frágil que as pessoas estão relutantes em refatorá-la – um acúmulo clássico de dívida técnica.

Sinais de condicionais excessivamente complexas

Como desenvolvedor, você deve estar atento aos sinalizadores vermelhos no código que sugerem que a complexidade condicional está fora de controle:

  • Níveis de aninhamento profundos: funções if com mais de 2 a 3 níveis de instruções aninhadas (especialmente com blocos intercalados else) são fortes candidatos. Visualmente, o código forma uma seta indentada para a direita, tornando difícil alinhar a lógica mentalmente. Se você se encontrar contando chaves ou recuos para descobrir quais pares else com os quais if, isso é um sinal ruim.

  • Cadeias longas de maiúsculas e minúsculas ou else-if: uma série de else if (...) { ... } else if (...) { ... } ... que continua para dezenas de linhas pode indicar que o código está tratando muitas variantes em um só lugar. Às vezes, uma instrução longa switch com muitos casos pode ser equivalente. Essas estruturas geralmente podem ser simplificadas ou divididas em partes menores (ou mapeamentos controlados por dados) se representarem várias condições estáticas.

  • Expressões boolianas complexas: condicionais que combinam muitos termos, por exemplo: if ((A && B && !C) || (D && (E || !F))) { ... } tais expressões são difíceis de ler e ainda mais difíceis de acertar. Se você vir a lógica condicional com vários operadores && e || misturados com negações !, a simplificação pode oferecer um benefício (por exemplo, dividindo em subcondições mais claras ou usando variáveis explicativas).

  • Expressões boolianas complexas: condicionais que combinam muitos termos, por exemplo: if ((A && B && !C) || (D && (E || !F))) { ... } tais expressões são difíceis de ler e ainda mais difíceis de acertar. Se você vir a lógica condicional com vários operadores && e || misturados com negações !, a simplificação pode oferecer um benefício (por exemplo, dividindo em subcondições mais claras ou usando variáveis explicativas).

  • Verificações repetidas e duplicação de código: procure casos em que a mesma condição ou código semelhante apareça em vários branches. Por exemplo, se você vir if (user.IsAdmin) em duas partes diferentes de uma escada if/else, será possível avaliar a condição em um único local se você reestruturar a lógica. Você também pode encontrar duas ramificações de uma condicional que contêm lógica de código semelhante, mas com pequenas diferenças. Se você observar esse padrão, o condicional poderá ser refatorado para evitar a duplicação.

  • Uso de variáveis de "sinalizador" para controlar o fluxo: às vezes, os desenvolvedores introduzem sinalizadores temporários como uma solução alternativa para lógica complexa (por exemplo, bool isValid = false; ... if (condition) { isValid = true; } ... if (isValid) { ... }). Embora o uso de sinalizadores não seja o mesmo que aninhar condicionais, geralmente é uma resposta à complexidade — o código não poderia fazer facilmente o que precisava em uma passagem e, portanto, define um sinalizador para ser verificado mais tarde. Você pode eliminar esse padrão reestruturando condicionais ou usando retornos imediatos.

Resumo

As condicionais complexas geralmente surgem de alterações incrementais, correções de bugs e requisitos em evolução sem acompanhar a refatoração. Os sinais de condicionais excessivamente complexas incluem aninhamento profundo, cadeias longas de condições, expressões boolianas complexas, verificações repetidas e o uso de variáveis de sinalizador. Reconhecer esses padrões é o primeiro passo para melhorar a qualidade do código por meio da refatoração.