Um programador tarimbado sabe que a melhor situação da vida dele para corrigir um bug é quando esse bug acontece em sua máquina de desenvolvimento, na versão Debug e ainda passo-a-passo. Como nessa situação a correção é um verdadeiro "passeio no parque" (ou na mesa do café) ela tende a quase nunca acontecer. Isso é Murphy Aplicado.
Para quem programa para sistemas, então, só o fato de acontecer no mesmo processo toda vez que ele for executado já é o máximo (quem já programou serviços, plugins, GINAs e afins sabe do que eu estou falando).
Porém, saber que uma determinada situação é mel na chupeta (by Thiago) por si só não adianta de muita coisa. É preciso conhecer as verdadeiras técnicas ninjas que conseguem resolver um bug escabroso num instante, coisa de deixar seu gerente de projetos tão feliz ao ponto dele não botar nenhum defeito na solução.
Dentre as mais conhecidas entre os malloqueiros, temos:
- Comenta-descomenta-comenta
- Faz do zero
Essas duas técnicas são tão úteis e tão fáceis de usar que merecem um artigo a respeito.
Tira-põe-deixa-ficar
Essa técnica milenar corresponde em tirar pedaços do código-fonte que poderiam estar causando o problema até que seja possível criar uma versão em que o problema não ocorra mais. Quando chega-se nesse nível, então volta-se a descomentar o código retirado até que o problema ocorra novamente. O processo é um fluxo de tira-código com volta-código, sendo que é necessário o bom conhecimento do projeto para não gerar outros problemas com a mutilação temporária do projeto.
Projeto-esqueleto (Re-Main!)
Se o código começa a ser tão mutilado que chegamos quase em uma versão vazia (sem código), então talvez a melhor forma de atacar o problema seja criar um esqueleto que contenha apenas o código necessário para que ele não faça nada. Isso mesmo. Não fazendo nada, mas instalado. Com isso prova-se que é possível estar lá sem fazer cagadas. A partir daí vai colocando-se o código do projeto real aos poucos no projeto-esqueleto, até que ele apresente o problema. Ou não. Já vi casos em que todo o código foi migrado e o problema sumiu. Ce la vie.
February 1st, 2010 at 10:16 am
Erro em produção, usuários com raiva, contrato comprometido e 3 dias de investigação. A técnica que nos salvou foi Comenta-descomenta-comenta. Excelente.
February 1st, 2010 at 8:13 pm
Excelente tópico, não poderia ter vindo em melhor hora.
Semana passada rachei a cabeça em cima de um projeto em .NET (C#), no qual eu adicionei alguns arquivos-fonte de um outro projeto, muito similar, que já estava prontinho - bastava alterar uma coisa ou outra nos fontes acrescentados. O problema aparecia na compilação: toda vez ele reclamava que "não foi possível carregar a referência", referindo-se às referências de página, que apontavam para os namespaces do projeto do qual originalmente faziam parte os arquivos que eu usara como templates no meu novo projeto.
É claro que eu tinha alterado os nomes das referências e seus devidos namespaces, porém o erro persistia, incansavelmente. A solução veio de um colega, que simplesmente sugeriu criar os arquivos em branco dentro do projeto, e em seguida ir copiando o conteúdo dos arquivos-template para dentro do esqueleto dos recém-criados arquivos. Funcionou.
Vai saber... ;-O
February 2nd, 2010 at 4:54 pm
Agora talvez fosse interessante postar sobre as piores técnicas de debugging em código - a minha contribuição para tal post, seria citando a famigerada técnica do "Bilhetinho" (ou "Trilha de Migalhas", ou ainda, técnica "João e Maria"), a qual consiste daqueles malditos MsgBox("Passou por aqui!!") que acabam ficando espalhados pelo código inteiro, por algum programador "gênio" que nunca ouviu falar em breakpoints (e pior - o cara esquece de apagar depois, deixando todo o trabalho para algum infeliz que tem que fazer manutenção no código).
Coisas de quem estudou programação "Porque meu primo disse que dava $$)...
February 10th, 2010 at 1:17 am
Werner,
Sobre as piores técnicas, para mim, o ganhador invicto é a "não-depuração": o indivíduo se recusa a depurar o código "rodante" de qualquer forma, se limitando a dar uma espiadela no código-fonte, coçar a cabeça e gastar horas pesquisando na internet o motivo do GPF. Isso sim, vai entender...
[]s
February 12th, 2010 at 8:33 pm
Wanderley,
Pelo que eu vejo hoje em dia, se o cidadão gasta algum tempo no Google pode se considerar um "troubleshooter"...
Pelos posts que eu vejo hoje em dia, em fórums de discussão, tem gente q pergunta cada coisa - se você tiver uns cinco minutos sobrando, dê uma espiada no que a criatura me pergunta depois da solução que eu postei aqui... é de chorar lágrimas de sangue.
Resumindo, hoje em dia não basta só dar a solução de bandeja - tem que ser do jeito certinho, pra criatura só precisar fazer o cut-and-paste sem mudar nada!
Vivemos o fim dos tempos, irmão!!
February 13th, 2010 at 2:12 am
Olá, Werner.
Fim dos tempo? Imagina! Essa é a glorificação de pessoas como você e eu, que sabem que uma boa pesquisa e um bom cérebro vão longe. Enquanto a grande massa não-pensante continua não-pensante, somos nós que devemos trilhar todos os caminhos do conhecimento, e, o melhor de tudo, ganhando por isso =)
[]s