DEV Community: Bruno Egito

Refatorar Ifs Não Significa Eliminar Decisões

Bruno Egito — Mon, 15 Dec 2025 00:17:13 +0000

Já falei sobre Object Maps, uma técnica poderosa para substituir cadeias de switch ou if/else. Com ela, trocamos complexidade ciclomática por acesso direto em tempo constante (O(1)), tornando-a ideal para cenários de mapeamentos estáticos do tipo chave → valor.

No entanto, o desenvolvimento de software no mundo real raramente é tão previsível. No dia a dia, lidamos com regras de negócio dinâmicas, faixas de valores, validações combinadas e decisões dependentes de contexto, situações em que um simples mapeamento deixa de ser suficiente.

É aí que surge a dúvida inevitável:
se não consigo eliminar o if, estou condenado a escrever código sujo?

A resposta é não. Refatorar condicionais não é um esporte onde ganha quem tem menos linhas de código (se fosse assim, bastava então usar o minifier :D), mas sim quem tem o código mais claro. A proposta hoje vai além de sintaxe. A meta é parar de escrever condicionais defensivas e começar a escrever intenção.

Vamos ver como aplicar Early Return, Encapsulamento e até mesmo o polêmico Switch da maneira coerente.

O Inimigo: A Programação Defensiva

Tive um professor na faculdade que, ao ensinar lógica de programação, apresentou uma regra que ia além do que normalmente se encontra na literatura. Um if isolado é perfeitamente aceitável. Dois, talvez acompanhados de um else, ainda exigem apenas atenção. Mas, a partir do terceiro, é um sinal claro de alerta: a probabilidade de a lógica ter sido mal modelada cresce significativamente.

Em essência, o tipo de if que mais polui o código não nasce da complexidade do domínio, mas da desconfiança. É o código que, antes de executar o que realmente importa, precisa validar, checar e reconfirmar uma série de condições defensivas. O resultado é conhecido: é um Arrow Code, onde a lógica principal se perde em meio a níveis crescentes de indentação e decisões encadeadas.

// ❌ Código Defensivo e Aninhado
function processOrder(order?: Order) {
  if (order) {
    if (order.isActive) {
      if (order.items.length > 0) {
        if (order.balance >= order.total) {
           // Finally, the actual logic...
           console.log("Processing...");
        }
      }
    }
  }
}

O problema aqui não é a existência da validação, mas a carga cognitiva. Você precisa ler 5 linhas de "ruído" para achar a lógica de negócio.

A Limpeza: Early Return (Guard Clauses)

A primeira estratégia para organizar a casa é o Early Return (ou Guard Clauses).

A regra é simples: trate as exceções primeiro. Se uma condição impede o código de rodar, retorne imediatamente. Isso elimina a necessidade de else e remove níveis de indentação.

// ✅ Guard Clauses: Limpando o fluxo
function processOrder(order?: Order): void {
  if (!order || !order.isActive) return;
  if (order.items.length === 0) return;
  if (order.balance < order.total) return;

  // O "Happy Path" fica livre e na raiz da função
  console.log("Processing...");
}

Beeem melhor, neh? Mas ainda estamos lendo implementação. Estamos lendo saldo < total, quando deveríamos estar lendo uma regra de negócio.

Escrevendo Intenção (Encapsulamento)

Aqui está o pulo do gato para um código maduro. Se o seu if verifica múltiplas variáveis ou regras específicas, não exponha essa matemática na função principal. Dê um nome a ela.

Em vez de escrever código que verifica pedaços de dados, escreva código que pergunta se uma regra foi satisfeita.

// ❌ Leitura de implementação
if (user.age >= 18 && user.hasLicense && !user.isSuspended) {
  rentCar();
}

// ✅ Leitura de Intenção (Predicados)
const canRentCar = (user: User): boolean => 
  user.age >= 18 && user.hasLicense && !user.isSuspended;

if (canRentCar(user)) {
  rentCar();
}

O if continua lá. O processador vai executar a mesma comparação. Mas para quem lê (você no futuro), a complexidade foi abstraída. Você parou de ler código defensivo e passou a ler a intenção do negócio.

A defesa do Switch: Roteamento vs Lógica

Muitas vezes, a complexidade não é booleana (sim/não), mas categórica (Tipo A, Tipo B, Tipo C). Nesses casos, o Object Map do artigo anterior é ótimo, mas e se precisarmos de lógicas complexas para cada tipo?

É aqui que o switch (ou cadeias de if) costuma virar um monstro de código espaguete, violando o princípio DRY (Don't Repeat Yourself).

O segredo para usar switch sem culpa é entender seu propósito: Ele deve ser um Roteador, não um Processador.

Utilize o switch apenas como uma Factory (Fábrica). Ele decide qual estratégia usar, mas a execução da lógica fica isolada em outro lugar (Classes ou Funções).

O jeito errado (Lógica Acoplada)

function calculateShipping(type: 'EXPRESS' | 'STANDARD', weight: number) {
  switch (type) {
    case 'EXPRESS':
      // Lógica pesada misturada com a decisão
      const rate = getTaxRate();
      return (weight * rate) + 10; 
    case 'STANDARD':
      // Mais lógica misturada...
      if (weight > 30) throw new Error('Weight limit exceeded');
      return weight * 5;
  }
}

O jeito certo (Factory + Strategy)

Aqui, o switch serve apenas para escolher o especialista.

// As regras de negócio ficam isoladas (Strategy Pattern)
const ExpressShipping: ShippingStrategy = { 
  calculate: (weight) => (weight * 10) + 10 
};
const StandardShipping: ShippingStrategy = { 
  calculate: (weight) => weight * 5 
};

// O Switch serve APENAS para criar/rotear (Factory)
const getShippingStrategy = (type: 'EXPRESS' | 'STANDARD'): ShippingStrategy => {
  switch (type) {
    case 'EXPRESS':  return ExpressShipping;
    case 'STANDARD': return StandardShipping;
    default:         throw new Error('Invalid shipping type');
  }
};

// Uso Limpo
const strategy = getShippingStrategy('EXPRESS');
strategy.calculate(10);

`If` e `Switch` não são o vilão

Eliminar ifs não deve ser um objetivo em si, mas o efeito colateral de um bom design.

O problema surge quando condicionais passam a compensar a ausência de estrutura, nomes semânticos e limites claros no código. Nesse cenário, o if vira defesa. O switch vira gambiarra. E a lógica de negócio se perde no meio do caminho.

Quando decisões estão bem distribuídas, Object Maps para mapeamentos estáticos, Guard Clauses para validações, Regras de negócio explícitas e Switches atuando como roteadores, o código deixa de ser reativo e passa a ser declarativo.

Você não elimina decisões.

Você elimina ruído.

E esse é o tipo de código que continua legível mesmo depois que o contexto do problema já não está mais fresco na memória.

Trocando complexidade ciclomática por O(1) com Object Maps

Bruno Egito — Sun, 14 Dec 2025 23:57:08 +0000

Sabe aquela sensação de pisar em ovos toda vez que você precisa mexer em uma regra de negócio complexa, principalmente na UI?

Seja lidando com status de pedidos, gateways de pagamento ou níveis de permissão, manter a consistência do código muitas vezes parece caminhar por um campo minado.

A reação natural de muitos devs (e isso me lembra muito o meu começo :D) é jogar essas variações em um switch ou em uma sequência infinita de if/else. O problema é que basta esquecer um único case ou errar um encadeamento e pronto: você tem um bug silencioso rodando em produção.

Muitos tentam resolver isso aplicando Guard Clauses (o famoso "return early"). É uma técnica excelente para limpar validações e evitar o aninhamento excessivo. Aliás, esse é um tema que rende um post dedicado só para ele no futuro.

Mas a proposta hoje vai além. Não quero apenas organizar os `ifs`, eu quero eliminar eles.

A meta é parar de escrever condicionais defensivas e começar a escrever intenção.

Quando lidamos com regras previsíveis, Object Maps combinados com Mapped Types oferecem uma abordagem muito mais robusta. A grande sacada é transformar a fragilidade das condicionais na segurança de um contrato.

👇 Como eu aplico isso na prática:

Em vez de espalhar lógica de controle imperativa, eu crio uma estrutura de dados declarativa e exaustiva.

📱 O Caso Real (React Native + Zustand)

Imagine um app de delivery onde cada status de pedido define: texto, cor, permissão de cancelamento e ação ao clicar.

Sem Object Map, isso vira lógica espalhada pela UI. Com o padrão, começamos definindo o domínio:

export type OrderStatus = 
  | 'pending' | 'confirmed' | 'preparing' | 'delivered' | 'cancelled';

type OrderStatusConfig = {
  label: string;
  canCancel: boolean;
  // Note que tirei a cor daqui. Já explico o porquê! 👇
}

Muitos colocariam um switch aqui. Mas vamos usar a tipagem a nosso favor com a sintaxe [K in Tipo]:

// O compilador obriga que TODAS as chaves de OrderStatus existam aqui.
type OrderStatusMap = {
  [K in OrderStatus]: OrderStatusConfig
}

export const orderStatusMap: OrderStatusMap = {
  pending: { label: 'orderStatus.pending', canCancel: true },
  confirmed: { label: 'orderStatus.confirmed', canCancel: true },
  preparing: { label: 'orderStatus.preparing', canCancel: false },
  delivered: { label: 'orderStatus.delivered', canCancel: false },
  cancelled: { label: 'orderStatus.cancelled', canCancel: false },
};

Se adicionar um novo status e esquecer de mapear, o TS quebra o build.

🔥 Uma abordagem mais pragmática

Se você quiser inferência de tipos mais precisa sem perder a checagem, o operador satisfies é perfeito. Ele valida se o objeto cumpre o contrato, mas mantém a tipagem literal dos valores.

export const orderStatusMap = {
  pending: { ... },
  confirmed: { ... },
   // ...restante
} satisfies Record<OrderStatus, OrderStatusConfig>

🎨 Separação de Responsabilidades (Domain vs UI)

Aqui está o "pulo do gato" para arquiteturas limpas. O seu mapa de regras (orderStatusMap) não precisa conhecer o seu Design System. Podemos criar um segundo mapa com responsabilidade única de vincular status ao tema:

// Vinculando chaves do status às chaves do seu tema
// (Ex: NativeBase, Restyle, etc)
export const orderStatusColorMap = {
  pending: 'warning',
  confirmed: 'info',
  preparing: 'orange',
  delivered: 'success',
  cancelled: 'danger',
} satisfies Record<OrderStatus, keyof ThemeColors>

🚀 Consumindo na UI (Zero `Ifs`)

No componente React Native, a lógica desaparece. Tudo vira acesso direto:

// Zustand
import { create } from 'zustand'

type OrderStore = {
status: OrderStatus
setStatus: (status: OrderStatus) => void
}

export const useOrderStore = create<OrderStore>(set => ({
status: 'pending',
setStatus: status => set({ status }),
}))

export function OrderStatusView() {
  const { t } = useTranslation();
  const status = useOrderStore(state => state.status);
  const theme = useTheme();

  // Desestruturação direta da regra de negócio
  const { label, canCancel } = orderStatusMap[status];

  // Resolução da cor via Design System
  const color = theme.colors[orderStatusColorMap[status]];

  return (
    <>
      <Text style={{ color }}>{t(label)}</Text>

      {canCancel && (
        <Pressable onPress={() => console.log('Cancelar')}>
          <Text>Cancelar pedido</Text>
        </Pressable>
      )}
    </>
  )
}

🧠 Indo além

Esse padrão não é só para UI. Imagine lidar com PIX e Cartão processados por gateways diferentes (Stripe, Mercado Pago).

Em vez de condicionais aninhadas, usamos um Object Map que retorna a estratégia correta de execução:

export const paymentStrategies = {
  pix: async (data, gateway) => {
    return adaptersMap[gateway].pix(data)
  },
  credit_card: async (data, gateway) => {
    return adaptersMap[gateway].creditCard(data)
  },
} satisfies Record<PaymentMethod, PaymentHandler>

// Uso na aplicação:
// A lógica "escolhe" a função correta e já executa.
const result = await paymentStrategies[method](negotiation, selectedGateway);

Por que isso muda o jogo?

Complexidade O(1): Removemos o custo cognitivo de ler múltiplos elses.
Paz de espírito: Se eu criar um novo status ou método de pagamento, não preciso caçar onde colocar o if. O compilador me guia apontando o erro.
Contratos Claros: O código deixa de ser defensivo e passa a expressar intenção.

E você, costuma usar Object Maps ou ainda confia na memória para manter seus switch cases atualizados? 👇

Decisões demais, estratégia de menos

Bruno Egito — Sun, 14 Dec 2025 01:49:41 +0000

Em muitos projetos, especialmente sob pressão de prazo, fazemos escolhas conscientes de assumir débito técnico. Isso faz parte da realidade. Clean Code e Clean Architecture têm um custo, e nem sempre há tempo ou contexto para pagar esse preço no momento certo.

O problema começa quando essas decisões deixam de ser estratégicas e passam a ser apenas reativas.

Nos últimos tempos, revisando projetos e PRs, venho percebendo um padrão recorrente: lógicas que crescem apoiadas em longas cadeias de if/else ou switch/case. Na maioria das vezes, isso não nasce de descuido, mas de pequenas decisões acumuladas, feitas para resolver o problema imediato.
Talvez não seja sempre possível aplicar Clean Code ou Clean Architecture da forma ideal.

Ainda assim, compreender as estruturas de dados e desenhar uma lógica simples para sustentá-las é o mínimo para evitar que o código se deteriore rapidamente.

E aqui entra um ponto importante: nem toda melhoria exige uma grande refactors ou uma reestruturação arquitetural completa. Muitas vezes, é possível simplificar a lógica, melhorar a estratégia e escolher melhor as estruturas de dados, reduzindo complexidade sem introduzir riscos relevantes no projeto.

Não se trata de buscar código perfeito, mas de evitar que decisões simples hoje se transformem em manutenção cara amanhã. Um mapa bem definido, uma separação mais clara de responsabilidades ou uma lógica mais declarativa já são passos suficientes para tornar o código mais previsível e menos frágil.

Essa reflexão foi o que me motivou a escrever uma sequência de artigos mais voltados para base lógica e estratégia. A ideia não é eliminar decisões, mas tomar decisões melhores, mesmo quando o contexto não permite o cenário ideal.

Porque, no fim, dívida técnica não é apenas o que deixamos de fazer. É, muitas vezes, como escolhemos resolver o problema.