Desde os primeiros softwares, ocorreram erros. E com passar do tempo, com programas cada vez mais complexos, os erros se tornaram cada vez mais comuns. Esses erros acabaram por tendo o nome de bug.
Alguns bugs são pequenos e só causa pequenos desconfortos para os usuários, mas existem aqueles que geram prejuízos financeiros enormes.
E por conta disso as empresas e programadores desenvolveram diversas formas diferentes para minimizar os números de erros em um software.
Mas, porque mesmo sabendo que há um bug na soma do JavaScript, uma das linguagens mais usada por toda a internet, eles nunca o corrigiram?
Etimologia
O termo “bug” antecede aos computadores, um exemplo disso é da década de 70, de 1870, quando por exemplo Thomas Edson escreveu uma carta ligando a palavra “Bugs” referindo-se a erros mecânicos.
Em 1930, uma propaganda de um pinball chamado Baffle Ball que não usava nem se quer eletricidade, usou o termo “livre de bugs” em seu panfleto de propaganda.
Mas para computadores, sua aparição ocorreu com um dos primeiros computadores eletromecânico, o Harvard Mark II.
Quando os operadores buscavam por um erro que estava ocorrendo, e acabaram achando um inseto preso em um relé desse computador, inseto que inglês é “bug”. Grace Hopper então registrou isso no livro de registro, anexando o próprio inseto no livro.
Desde então, o uso do termo ‘bug’ em informática começou a ser cada vez mais utilizado.
Bugs Famosos
Mas o que alguns bugs podem fazer de ruim para nós? Talvez uma tela azul, ou um travamento do seu jogo preferido? E se houver bugs em sistemas mais críticos??
Em 1999, o Mars Climate Orbiter, uma sonda da NASA, se aproximava de Marte para orbitá-lo, mas algo deu errado, e ele se aproximou demais de Marte e foi perdido para sempre, gerando 125 milhões de dólares de prejuízos, mas o que aconteceu??
Após de alguns meses de investigações, descobriram um erro de comunicação entre centro de operações na terra e a sonda, o que aconteceu é que os dados de telemetria que a sonda enviava estava em sistema métrico, padrão que a NASA adotou desde o início dos anos 90, enquanto o centro de operações analisou os dados como sistema imperial, gerando distorções nos resultados finais, fazendo com que a sonda se aproximasse até 57km da superfície de Marte, chegando a sua atmosfera e destruindo totalmente.
Porém a história nos conta um bug muito mais famoso que pode ter trago mais de 500 bilhões de dólares em prejuízos! Sim estou falando do bug do milênio.
Tudo começa pelo fato de que os computadores antigos guardavam o ano com apenas 2 dígitos, tudo porque memória naquela época era extremamente cara. O que aconteceria é que, ao chegar no ano 2000, o último ano do milênio, os computadores iriam interpretar como ano 1900.
E dependendo do sistema, esse erro poderia gerar mais prejuízos, então houve uma corrida no mundo todo contra o tempo para corrigir todos os erros possíveis.
Felizmente não houve erros graves, alguns podem ter gerados certos desconfortos ou apenas mostrar a data errada em algum lugar. Outros erros só foram descobertos no fim do ano 2000, quando alguns sistemas não reconheceram o ano 2000 como um ano bissexto.
Aliais, datas é um problema a parte para programadores, tem problemas com ano bissexto, com ano 2010, 2038 tem problema de tudo que é tipo e gosto para programadores se divertirem.
Bugs Herdados ou Mantidos
Mas será possível que a Microsoft lançaria um produto profissional como Excel com um bug propositalmente?
Sim!!! O Excel tem um bug que foi criado propositalmente e é mantido até hoje por conta de uma decisão dos desenvolvedores lá no início de sua vida, como Lotus 1-2-3 era um dos softwares de planilha mais utilizados dos anos 80, a Microsoft decidiu em manter um bug dele em seu novo aplicativo de planilhas, o Lotus 1-2-3 reconhecia incorretamente o ano 1900 como um ano bissexto, aceitando a entrada da data de 29/02/1900.
O objetivo era facilitar passar as planilhas de Lotus 1-2-3 para o Microsoft Excel.
Mas essa não é a única vez que a Microsoft decidiu manter um bug. Quando o MS-DOS chegava em sua segunda versão, ele ganhava suporte a diretórios, porém não poderiam usar a barra padrão para separar as pastas que era usada nos sistemas Unix e da maioria dos outros sistemas operacionais da época, isso porque essa barra já era usada como entrada de opções de comando.
E para não confundir os usuários que já usavam a primeira versão do MS-DOS, a Microsoft decidiu em usar a barra invertida como separador de pasta e manter a barra como entrada de opções dos comandos.
Porém, não foi só a Microsoft manteve bugs propositalmente todos esses tempos, na verdade, qualquer site da internet pode ter um bug por conta de um erro no JavaScript.
Isso porque o JavaScript não consegue somar 0.1 com 0.2 corretamente, gerando um valor aproximado. No geral pode ser que esse pequeno erro não cause um problema, mas se o site precisa passar valores precisos de casas decimais, pode ser que o programador tenha que usar métodos alternativos de soma para chegar no resultado desejado.
Esse erro no JavaScript jamais foi corrigido e pode ser que nunca seja, por um motivo simples, programadores tomaram decisões para remediá-lo, se corrigirem esse bug, sites que hoje existem e funcionam corretamente, podem passar a fazer cálculos incorretos, gerando mais custos para empresas.
Assim como esses, muitos outros bugs foram criados ou mantidos propositalmente em diversos sistemas, algumas vezes para manter compatibilidade com outros softwares ou versões, outras vezes para não confundir usuário o utiliza.
Prevenção de Erros
Mas depois de tanto tempo, é natural que os desenvolvedores tenham criado formas de minimizar o máximo possível os bugs.
Podemos disser que o primeiro passo em minimizar os erros, foi quando as linguagens de desenvolvimento ficaram mais compreensivos para humanos.
Outro ponto que mudou no desenvolvimento, foi as evoluções das ferramentas de desenvolvimento, onde elas ajudam na prevenção de erros antes mesmo de acontece-las.
Mas somente isso não foi suficiente. E logo metodologias também foram criadas para prevenir erros.
Uma das técnicas que foram usadas para isso, foi por meio de especificações formais do programa, indicando o comportamento exato que ele deveria ter. Porém, essa técnica se tornou impraticáveis para maioria dos sistemas devido a explosão combinatória, que significa um rápido crescimento da complexidade de um problema, e também aos algoritmos não determinísticos, que é um pouco chato de explicar, então, acreditem, é algo que complicava.
Então precisávamos outras ideias para evitar erros, e foi quando apareceu o teste unitário, onde para cada função, o programador iria fazer um ou mais testes para certificá-lo. Eu chamo isso de prova real, pois tem exatamente a mesma ideia da prova real, porém no meio dos desenvolvimentos de software.
Em cima dessa ideia, alguns foram além criando o desenvolvimento orientado por testes, onde os testes são escritos antes mesmo do desenvolvimento da função em si.
Outra metodologia é o desenvolvimento de software ágil, onde o ocorre lançamentos frequentes do software, com mudanças pequenas e quando encontrado um defeito, ele já pode ser corrigido em um dos próximos lançamentos.
É claro que tudo isso, foi só uma pincelada sobre os assuntos de prevenções de erros, muitas coisas foram ignoradas ou explicada bem superficialmente, mas podemos entender que há todo um estudo por trás de prevenção de bugs! Mas e se tudo falhar?
Se tudo falhar, algumas empresas oferecem um programa de recompensa por bugs, qualquer um que encontrar um bug em um software, pode ser recompensado com dinheiro ou brindes.
A primeira empresa a fazer isso foi o falecido navegador Netscape, e a partir disso a ideia foi criando mais forças e aceita por mais empresas. Hoje a maioria das grandes empresas tem um programa de recompensa parecido, até mesmo o governo americano tem um programa do tipo.
Mas há outros programas com usuários finais que também ajudam a minimizar o bug, é programa de acesso antecipado, muito comum no mundo dos games, esse programa consiste em um usuário obter uma versão não finalizada do software, e usá-lo, os bugs e comentários são enviados para desenvolvedora e analisados e corrigidos antes do lançamento da versão final.
Fontes e Referências
- https://en.wikipedia.org/wiki/Software_bug
- https://pt.wikipedia.org/wiki/Falha_(tecnologia)
- https://en.wikipedia.org/wiki/Baffle_Ball
- http://www.devtopics.com/20-famous-software-disasters/
- https://en.wikipedia.org/wiki/Mars_Climate_Orbiter
- https://pt.wikipedia.org/wiki/Mars_Climate_Orbiter
- ftp://ftp.hq.nasa.gov/pub/pao/reports/1999/MCO_report.pdf
- https://en.wikipedia.org/wiki/List_of_software_bugs
- https://en.wikipedia.org/wiki/Year_2000_problem
- https://en.wikipedia.org/wiki/Year_2038_problem
- http://nomedojogo.com/2009/08/17/isto-e-um-bug-no-javascript/
- https://www.computerworld.com/article/2515483/enterprise-applications/epic-failures–11-infamous-software-bugs.html
- https://jsfiddle.net/16panjsw/1/
- https://en.wikipedia.org/wiki/Fail-silent_system
- https://en.wikipedia.org/wiki/Bug_compatibility
- https://en.wikipedia.org/wiki/Leap_year_bug
- https://en.wikipedia.org/wiki/Bug_bounty_program
- http://www.jargon.net/jargonfile/b/bug-compatible.html
Podcast: Play in new window | Download
