Entre um valium (café sem açúcar) e outro, lembrei que existe um catálogo de patterns para design orientado a objeto, outro para enterprise OO e mais um design pattern para refactoring, e para mim ficou claro que estudamos o como fazer, como escalar e como evoluir, mas e como consertar? Como fica?

Claro que achei que estava tendo uma ideia maravilhosa, algo que faltava etc., talvez pelo efeito do valium ou pelas histórias geniais sobre momentos Eureka que correm pelos sites de autoajuda ao lado de fotos de como perder peso em 2 semanas, mas não era o caso, ufa padrões de debug é um assunto com referências na web e até um verbete na Wikipedia.

Mesmo assim, entre o Eureka falso e a localização do verbete na Wikipedia, deu tempo de pensar em alguns patterns para “o catálogo maravilhoso de search/destrói de leprechauns” a la Dr. Seuss.

Aqui vai o DRAFT (repito, o DRAFT) do primeiro deles:

1º – Ponto de entrada

Define por onde se começa a pesquisa de um bug.
Resposta curta: Ou pelo método que realizou o output, ou pelo que requisitou o output.

Exemplo:
Você pede a lista de usuários utilizando a tela de cliente e uma chamada para o método getUsers recebe um dado da origem, número do cliente. O sistema recupera uma lista do banco de dados segundo esse número/id e renderiza na tela/saída.

Temos 3 componentes.

1) Quem requisitou a ação.
Esse componente é de interface com o usuário/cliente, seja o usuário um cronjob ou uma pessoa utilizando o software.

Muitas vezes, a requisição é parametrizada, e o erro pode estar nesses parâmetros. Muitas vezes, a requisição deve seguir um protocolo específico (cabeçalhos http, chuncks, formato de dado etc.) e não está fazendo isso corretamente.

2) Quem executou a ação.
O componente que executa a computação, normalmente uma chain de componentes, com delegações e inferências próprias.

Esse componente pode ser parametrizado, e o problema pode estar nos parâmetros.
Esse componente trafega uma mensagem na chain, e essa mensagem pode estar sofrendo algum efeito colateral e sendo alterada, ficando num estado inconsistente.

3) O output.
Aquele que apresenta os dados para o cliente.

Esse componente recebe informações que devem ser apresentadas. Ele pode estar lidando com um tipo de dado para qual não está preparado, estar com problemas em transformações nos dados para visualização ou não estar recebendo os dados.

Solução de menor custo

O menor custo de solução está quando o bug é encontrado no componente 1 e no 3, e ocorre com frequência de o bug estar realmente nesses dois itens, logo, eles são os melhores pontos de entrada para localizar um bug, em vez de começar a pesquisa pelo algoritmo que recupera a lista, o item 2.

Workflow de ataque:
Primeiro verifique 1, tendo certeza de que a requisição é feita da maneira correta; depois verifique 3, tendo certeza de que o output está sendo realizado da maneira correta. Somente depois verifique o ponto 2.

É isso, ainda tem outros 4 padrões de debug anotados, vou soltá-los com o tempo, mas eis a lista:

• subir método.
• descer método.
• nomear valores.
• usar amostra.
• matar para ver.

Por favor, tenha em mente que: sou um eterno estudante e, como todo bom estudante, procuro as melhores maneiras de saber (que as pessoas teimam em confundir com reconhecer), e que faço isso entre um valium e outro.

Obs.: meu valium não vem em pílulas.