Matem os Leprechauns, ou Catalogo de Padrões de Debug.

Debugging patterns, ou como localizar e matar os malditos leprechauns!

Entre um valium(café sem açucar) 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 pra mim ficou claro que estudamos o como fazer, como escalar, e como evoluir, mas e como consertar? Como fica?

e como consertar? Como fica?

Claro que achei que estava tendo uma ideia maravilhosa, algo que faltava e etc… talvez pelo efeito do valium ou pelas histórias geniais sobre momentos Eureka que correm pelos sites de auto-ajuda ao lado de fotos de como perder peso em 2 semanas usando a pílula do cocô feliz, 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:

1o- 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 usando 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.
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 do bug estar realmente nesses dois itens, logo, eles são os melhores pontos de entrada para localizar um bug, ao invés 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 soltando eles por aqui 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.

…e pra provar que ninguém lê essa bodega, vou imitar o magistrado, que com sua grande eloquência apresentou a petição da pamonha ao mundo:

Senhores julgadores, espero que entendam o que faço nestas pequenas linhas, e que não seja punido por tal ato de rebeldia, mas há tempos os advogados vem sendo desrespeitados pelos magistrados, que sequer se dão ao trabalho de analisar os pleitos que apresentamos. Nossas petições nunca são lidas com a atenção necessária. A maior prova disso, será demonstrada agora, pois se somos tradados como pamonhas, nada mais justo do que trazer aos autos a receita desta tão famosa iguaria. Rale as espigas ou corte-as rente ao sabugo e passe no liquidificador, juntamente com a água, acrescente o coco, o açúcar e mexa bem, coloque a massa na palha de milho e amarre bem, em uma panela grande ferva bem a água, e vá colocando as pamonhas uma a uma após a fervura completa da água, Importante a água deve estar realmente fervendo para receber as pamonhas, caso contrário elas vão se desfazer. Cozinhe por mais ou menos 40 minutos, retirando as pamonhas com o auxílio de uma escumadeira.

Advertisements

One thought on “Matem os Leprechauns, ou Catalogo de Padrões de Debug.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s