No dia 9 de setembro de 1945 a equipe da Dr. Grace Hopper (que mais tarde se tornaria a criadora da linguagem COBOL) e de Howard H. Aiken estava diante de um problema na sala do computador Mark II. Depois de uma análise minuciosa detectaram uma mariposa entre os contatos de um dos relés do computador. Ironicamente Grace documentou o incidente nos registros adicionando o inseto e a frase “First atual case of bug being found”.
Foto do que possívelmente seria o primeiro bug encontrado em um computador
Existe um efeito psicologico muito forte quando um erro explode em um software. É dificil para um profissional assumir que cometeu um erro ou deixou de testar adequadamente antes de colocar algo em produção. Quando um bug aparece, a tendencia é sempre procurar pelo culpado ao invés de procurar pelo problema.
Há alguns anos eu trabalhei em uma consultoria que mantinha uma lista na parede com um ranking dos programadores que mais deixavam bugs no código. Toda vez que um usuário ligava reclamando de algo, iniciava-se uma espécie de corrida para ver quem encontrava o culpado primeiro. Assim que o infeliz programador era apontado, ele era obrigado a vestir uma faixa com os dizeres: “Eu quebrei o código” durante todo o dia de trabalho.
Não é possível desenvolver um software isento de falhas. Infelizmente, os computadores ainda estão limitados a fazer aquilo que mandamos ele fazer, e não necessariamente aquilo que queremos que ele faça. E enquanto isso não se tornar uma realidade estaremos sempre em modo de manutenção.
Desenvolver é um ciclo que envolve escrever algo original por alguns minutos e então passar algumas horas solucionando bugs. Escrever um código novo e então reescrever algo que aparentemente ficou ruim. Todos os programadores deveriam ter isso em mente antes de ingressarem nessa profissão.
Um bom programador precisa inicialmente desligar todos esses sistemas instintivos de defesa. Eu sei muito bem o que é estar procurando por um bug no código com o gerente de um lado e o cliente do outro observando cada passo que você dá. Concentre-se, não perca o foco.
Pense em um médico. O paciente chega no consultório com dor de cabeça, nauseas, dor em certas partes do corpo, etc.. Se o médico tentar solucionar cada um dos sintomas de forma isolada ele estará mascarando o real problema do paciente. O objetivo é identificar o que está gerando todos esses sintomas. Ao localizar a raiz do problema e medicar o paciente corretamente, de forma natural todos os sintomas desaparecerão.
Da mesma forma, o maior erro que um programador pode cometer ao tentar resolver uma falha em um sistema é atacar os sintomas. Isso normalmente só confundirá a sua mente.
A maneira mais simples de encontrar um erro no código é explicando o problema para outro programador. A outra pessoa não precisa dizer uma única palavra, o simples fato de explicar passo-a-passo o que o código deveria fazer, normalmente é o suficiente para que você mesmo vislumbre o que pode estar causando a falha.
Pode parecer simples demais, mas ao explicar o problema para outra pessoa você terá de entrar em detalhes que talvez estejam passando despercebidos por você. Isso lhe dará uma nova visão do problema.
Solucionar bugs é parte da rotina de um programador. Algumas técnicas apenas diminuem a quantidade de incidencias no seu código, mas evitá-los totalmente é impossível. O mais importante é ter em mente que um erro no software, mesmo trabalhando em uma grande equipe nunca terá um culpado, ele sempre será um problema seu.
21 Comentários
Trackbacks
- Tweets that mention “Eu quebrei o código” | Nome do Jogo -- Topsy.com
- I’m here again | Luiz Claudio Moreira Junior
- Raciocine Digital » Você sabe qual foi o primeiro “bug” encontrado no mundo?
Fantástico!
Muito bom o post!!
E é bem verdade que explicar o problema ou às vezes até o código para seu par de programação pode te fazer visualizar onde você errou.
Supimpa.
Ótimo post, e muito bacana a história da Dr. Hopper :)
A melhor solução para bugs é uma segunda opinião ou novos olhos para o problema.
Simplesmente sensacional!
Realmente, muito legal.
Obs. inceto != inseto == bug
Saudosismo a parte, ja que também ja fui programador COBOL, gostei muito do post Brando. Parabéns!
@Luciano
Ops… corrigido. Malditos corretores ortográficos que não funcionam. ;)
Muito bom mesmo, parabéns!
Acho que não é nem necessário que a explicação seja para outro programador, eu mesmo já resolvi vários problemas explicando os mesmos para a minha namorada. O engraçado é que normalmente nem chego ao final da explicação, e ela fica com o mérito…. hehehehe
O que você disse sobre a melhor forma de identificar um bug é a pura verdade. Um dia ainda vou providenciar um espantalho para não precisar incomodar outros programadores… hehehe
“explicar o problema para outra pessoa você terá de entrar em detalhes que talvez estejam passando despercebidos por você.
Considero isso como um dos pontos fortes que podem auxiliar a detectar uma falha. Realmente funciona.
Já passei por essa experiência na hora do almoço com um amigo, e … funciona!
Interessante. Estava lendo no Livro Cultura Toyota, algo que tem bastante a ver com isso:
“Uma grande diferença entre a liderança na Toyota e o gerenciamento tradicional é que na Toyota, os lideres tem foco em confirmar o processo, e não procurar por erros das pessoas. Qualquer coisa fora do padrão é leva ao processo de resolução de problemas, e não de procura de alguém para culpar.”
Abraço,
André Faria
Realmente explicar o código para outra pessoa faz com que alguns mínimos detalhes sejam lembrados no momento da explicação, e o programador sai da pressão do trabalho por conversar, e se torna naturalmente mais aberto a receber outras questões neste caso dele mesmo.
Post fenomenal! Parabéns mesmo…
Show!!!
Quem nunca quebrou o código que atire a primeira pedra.
E concordo que realmente ensinando ou explicando algo, você pode vislumbrar a situação ou o problema de outro ângulo chegando assim na solução de forma impressionante!!!
Quem nunca quebrou o código que atire a primeira pedra. [2]
Isso, de explicar o problema para alguem e, assim, encontrar a solução do mesmo já aconteceu comigo várias vezes.
Também com colegas que chegam, a primeira vista pedindo ajuda sobre as eventuais causas e antes de acabarem de falar sobre o problema já descobrem a causa e a solução.
Simplesmente fantástico… já fiz isso sem nem notar… rsrs
Parabéns pelo artigo.
looooooooooooooooooool muito boa a matéria!Eu já quebrei o código, a cara, a paciencia e ainda estou na luta o iportante é tentar sempre mesmo tendo falhas independete de quantas tiver no programa continue como o própio comando em c … looooooooooooooooooool
muito bom o topico… me ajudara bastante =)
Fantástico!
Ainda estou aprendendo a programar, porem pelos comentários de quem já tem conhecimento ouvi varias vezes sobre isso “procurar quem errou ao invés de solucionar o erro”
Parabéns pelo artigo!
“Uma grande diferença entre a liderança na Toyota e o gerenciamento tradicional é que na Toyota, os lideres tem foco em confirmar o processo, e não procurar por erros das pessoas. Qualquer coisa fora do padrão é leva ao processo de resolução de problemas, e não de procura de alguém para culpar.”
+1