Tabela de decisão ganha do if aninhado, e não é por elegância.

A mesma política, dois formatos

Pegue uma política com três entradas: faixa de score, segmento do cliente e canal. Em forma de condicional isso vira uma árvore — checa o segmento, dentro dele checa a faixa, dentro dela checa o canal. A árvore funciona bem na hora em que você a escreve. O problema aparece na quarta edição, quando um ramo precisa de exceção e o movimento natural é aninhar mais um nível.

Como tabela, a mesma política é uma grade. Cada linha é uma combinação das três entradas e o resultado correspondente. Nada é aninhado, então nada fica mais fundo. Acrescentar uma exceção acrescenta uma linha.

A vantagem real: a ausência fica visível

Uma árvore de condicionais não conta o que ela não cobre. Um ramo faltando é idêntico a um ramo ausente de propósito — o código cai no padrão, em silêncio, e você descobre quando um cliente aterrissa ali.

A tabela tem forma. Se suas três entradas têm quatro, três e dois valores possíveis, existem vinte e quatro combinações, e dá para ver quantas linhas você tem. A diferença entre vinte e quatro e o número de linhas escritas é o número de casos em que você não pensou. Essa é uma pergunta que o próprio formato faz, sem você pedir, toda vez que você o abre.

A condicional aninhada esconde as lacunas. A tabela conta as lacunas para você.

Quem consegue revisar

A política é acordada por gente que não escreve código — um comitê de crédito, um líder de fraude, um compliance officer. Quando a política é uma árvore de condicionais, a revisão acontece por tradução: alguém da engenharia explica o que o código faz, e o revisor aprova a explicação, não o artefato.

É nessa lacuna que nasce a maior parte dos defeitos de política. Não na lógica, que costuma ser simples, mas na passagem entre o que foi acordado e o que foi implementado. A tabela fecha essa lacuna, porque o que o comitê aprova e o que executa são o mesmo objeto.

Quando a tabela é o formato errado

Tabelas servem para combinações de entradas discretas. Elas deixam de ajudar em três casos, e forçá-las é pior do que aninhar.

Conta contínua

Um cálculo de capacidade de pagamento ou um índice é aritmética, não consulta. Calcule primeiro, depois divida o resultado em faixas e deixe a tabela ler a faixa.

Lógica de fato sequencial

Quando o passo dois só faz sentido dado o resultado do passo um, isso é um fluxo com ramificações, não uma grade. Modele como ramificação e mantenha as tabelas dentro dos ramos.

Uma entrada, muitos limiares

Um corte de eixo único é uma regra. Uma tabela com uma coluna é uma tabela fingindo ter motivo para existir.

Como isso fica em um fluxo

Na prática os formatos se combinam. Na ArboRule, um nó de Código deriva os índices, um Scorecard transforma características em pontos, uma Tabela de Decisão liga faixa de score, segmento e canal a um resultado, e uma Matriz 2D cuida das grades de dois eixos, como limite por score e renda. Um nó de Regra carrega os bloqueios de condição única que não merecem uma grade.

Essa composição importa mais do que qualquer formato isolado. O modo de falha não é escolher tabela em vez de condicional — é ter um artefato só, misturando derivação, pontuação e política, de forma que mudar um corte exija ler aritmética para encontrá-lo.

Perguntas