Achei uma pergunta sensacional no StackOverflow feito pelo Jefferson Quesado acompanhada de uma excelente resposta do RBZ que gostaria de compartilhar em meu blog. Sempre chamei de bugs mágicos o que agora soube que a terminologia correta é heisenbug. Segue abaixo a pergunta e a resposta:
Um heisenbug é um bug que muda seu comportamento ao ser estudado [1]. Ele tem seu nome derivado devido ao princípio que Heisenberg detectou que a simples “observação passiva”* de processos quânticos alteram o resultado final.
Heisenbugs típicos acontecem com condições de corrida, pois qualquer tipo de medição que você faça (como trace debugging ou break points) acaba por sincronizar os processos concorrentes de uma forma ou de outra.
*: Na física quântica não existem observações puramente passivas, mas isso são detalhes
Então, imaginem que estou numa situação complicada tentando resolver um problema no sistema e até consigo reproduzir o bug, mas quando eu tento ver mais coisas sobre o bug colocando um break point estratégico, esse bug deixa de acontecer. Nesse momento, me deparo com aquela situação:
“OMG! Um heisenbug!”
O PHB me pergunta o que está acontecendo. O suporte está com o cliente na linha. Preciso dar uma resposta sobre como está o andamento do estudo desse problema, preciso pedir mais tempo para tentar sanar porque não é um bug simples, mas um heisenbug!
Como consigo explicar para o chefe e para o suporte sobre o heisenbug? Eles não são os mais profundos conhecedores da programação, acham que só por um if (stuff_will_bug()) { dont_do_stuff(); } else { do_stuff(); } resolve o problema magicamente.
*: De preferência, explicações que não resultem na minha demissão
Pelo que entendi, você precisa de uma analogia, assim facilitar explicar algo complexo, para um leigo em programação (seu chefe).
Explicando com minhas palavras ao meu chefe (leigo) (pode ser melhorado, sempre!):
Na minha opinião, a Analogia 2 e Analogia 3 estão mais claras, mas vale a pena ler as demais.
Analogia 1 – Ônibus quebrado
Fato
Sou dono de uma empresa de Transporte coletivo.
Problema
Tenho um ônibus que sempre quebra o amortecedor.
Debug
O motorista de ônibus sempre percorre exatamente o mesmo percurso.
Com isso, irei junto a ele, e assim verificar o que está havendo.
Mas “incrivelmente” as vezes que fui junto, o ônibus não quebrou! Por quê?
Solução
Após suspeitas, foi acompanhado o problema de forma não tão invasiva, colocando um “espião” disfarçado de passageiro, e bingo!
Existe um buraco enorme em uma das ruas do trajeto, e o motorista nem sequer desvia deste buraco, a não ser, que esteja sendo observado.
Resumindo
Só o fato de estar sendo observado, resultou na correção temporária do problema.
Analogia 2 – Cadê meu bife?
Fato
Trabalho na empresa XYZ e sempre levo marmita para o almoço, onde deixo na geladeira comunitária que tem no serviço.
Problema
Como eu faço o 2º horário de almoço, todo dia está “sumindo” um bife da minha marmita.
Debug
Devido ao problema, comecei a passar pelo refeitório no primeiro horário de almoço. E assim, meu bife parou de “sumir”. Por quê ?
Solução
Havia um funcionário, que ao ir buscar a própria marmita, abria outras marmitas e pegava os bifes (fator fora de sua “instrução” correta). Isso foi descoberto, observando e analisando todos os “recursos” (funcionários), até chegar no recurso causador do problema, onde o mesmo, visualmente não estava ligado diretamente ao problema, mas com um fator de “intervenção” (eu) alterava o resultado final.
Neste caso tem-se 3 soluções:
- Mandar o funcionário embora (eliminar o recurso/processo)
- Colocar câmeras (criar recurso complementar que filtra a falha)
- Aplicar advertência (correção, com possibilidade de solução temporária)
Resumindo
Idem a Analogia 1, com exemplo de 3 possíveis soluções mais concretas.
Analogia 3 – Entra e Sai do Fusca (fato verídico)
Fato
Tenho um Fusca 1947!
Problema
Às vezes quando estou andando de Fusca, ele para de funcionar de repente. Encosto e tento dar partida várias vezes, mas de forma alguma funciona.
Debug
Antigamente, se ouvia que, quando o Fusca desse esse problema, você deveria sair do veículo por 2 minutos, entrar novamente, dar partida, e ele iria ligar.
De fato, feito e comprovado!
Solução
Após entender melhor a parte mecânica (estrutural), foi descoberto que a “bobina” esquentava e fazia a parte elétrica parar.
O fato de entrar e sair do veículo e esperar 2 minutos, fazia com que ela esfriasse o suficiente para voltar a funcionar.
Resumindo
Mais um exemplo, de um terceiro fator chave que não era nem imaginável e notável, e quando tentávamos uma solução fora de lógica mas que funcionava paliativamente, acabávamos “viciando” nosso raciocínio em um “ponto de partida” incorreto.
Tássio Auad 