Erros de programação

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on telegram
Share on pocket

A proliferação de equipamentos controlados por microprocessadores programáveis e aplicativos deixa o usuário à mercê de erros de programação.

 

Tem sido muito comum, de décadas para cá, uma pessoa entrar em uma loja, comprar um aparelho, sem saber que está levando para casa um equipamento que contém um software que gerencia as suas funções.

Ao chegar em casa esta pessoa se depara com um erro na função programada e irá intuitivamente achar que o defeito está no hardware, quando na realidade ele é fruto de um programa mal escrito!

Programas mal escritos não são difíceis de achar em qualquer equipamento, e é para isso que deve ser feita uma previsão de revisão do código (processo tecnicamente chamado de “debugging”) e quando tudo estiver certo a reinstalação do código revisado deverá ser realizada.

Um dos piores tipos de erro é o que se convenciona chamar de “erro de lógica”: o programa erra de forma equivocada, realizando uma determina operação completamente fora do que era originalmente pretendido. E, em alguns casos, o programa funciona, aparentando estar correto, mas sem chance de fazer a operação desejada.

A seguir, vou dar um exemplo contundente de uma programação com este tipo de erro: anos atrás eu comprei um carro com um sofisticado painel multimídia. Ao inserir nele um drive USB, eu notei imediatamente que a ordem das músicas estava alterada. E eu fui investigar por quê.

Quando se copia uma mídia (CD, por exemplo) para um drive, o programa que faz a cópia a faz de acordo com a ordem das faixas, 01, 02, etc. Não há como errar, principalmente no caso de mídia comercial, quando então a autoração é obrigatoriamente ordenada desta maneira. São arquivos com a extensão “.cda” convertidos em tempo real para outro formato de áudio, como MP3, por exemplo. Se a lista resultante é lida corretamente pelo reprodutor de mídia, esta ordenação será mantida, porque ela é baseada nas convenções da antiga tabela ASCII.

O CD “Maximum”, usado neste exemplo, e gravado pela banda de Max Greger, tem a seguinte ordem nas faixas:

 

Pela lógica, a reprodução começaria com “O1 Salute To Miles”, mas começa no mídia player com erro por “06 Bossa Fluta”. N.B.: na realidade, o título é “Bossa Flauta”, mas enfim…

Isso porque quem escreveu o programa de leitura do media player se baseou na informação do título da faixa contida nos metadados dos arquivos, e fez uma ordenação alfabética, de acordo com esta informação. Os metadados da faixa 01 são:

 

 

O título da faixa 01 (“Track Title” nos metadados) começa com “S”, então a sua reprodução vai parar na sexta posição, se os meus cálculos estiverem corretos. E não adiantou mudar parâmetros de ordenação, porque o reprodutor continuou cometendo o mesmo erro. Eu notei, inclusive, que as faixas dos discos com metadados em branco aparecem na tela com a ordem de diretório correta!

Falta de comunicação e ausência de responsabilidade de quem escreve o código

Resumindo a ópera: uma vez notado o erro, eu liguei imediatamente para a fábrica, a moça mandou que eu fosse na concessionária. Pois bem: eu imprimi um esquema detalhado, com ilustrações que convenceriam qualquer um que havia ali um erro de lógica. Mas, o chefe da oficina, que me ouviu com paciência, cuja especialidade profissional está longe da informática, não entendeu patavinas, e o assunto ficou por isso mesmo.

Dias depois, alguém do SAC da fábrica me pergunta se eu estava satisfeito com a compra, e eu, claro, disse que no tocante ao reprodutor de mídia, eu achava aquele erro absurdo. Imagine tocar um concerto de qualquer coisa ou um álbum cuja ordenação de faixas é proposital, e depois ficar ouvindo este material fora de ordem, por conta de um erro facilmente corrigível!

Aí a pessoa do outro lado da linha me diz que iria investigar isso, mas no final nada aconteceu. Não há desculpa, porque a troca de programação de uma central dessas é factível por uma simples reinstalação do código via porta USB. Em última análise, a concessionária tem um programa que é frequentemente usado para reconfigurar o carro. Este programa eu já vi rodando a partir de um notebook, que é ligado em um soquete embaixo do painel. Com ele se corrige tudo!

Ora, trata-se de um fabricante de automóveis. Imagina-se que eles terão recursos para resolver qualquer coisa, mas não foi o caso. Isso é o que dá ninguém ouvir o cliente. Não adianta fazer esquema, mostrar o erro, etc. Simplesmente não existe câmara de ressonância no fabricante, que poderia perfeitamente chamar quem escreveu aquele programa e solicitar explicações e/ou correções.

Nada disso me causa surpresa. Na década de 1990, os primeiros reprodutores de DVD foram lançados no Brasil. A programação dos microprocessadores, é globalmente feita por uma única programação de “firmware” (nome genérico do programa associado ao microprocessador), gravado em memória “flash”, não volátil e reprogramável.

Pois no Brasil, atualização de firmware era tabu nas fábricas. Tempos depois, e isto provavelmente foi pressão de consumidores insatisfeitos, as fábricas começaram a se prontificar em atualizar o firmware, mas somente dentro das oficinas autorizadas. Se o usuário fizesse fora, perdia a garantia.

Até hoje, reprodutores de mesa e vários outros tipos de equipamentos, uma vez conectados à Internet, permitem a atualização on-line do firmware, mas a fábrica nem mesmo assim recomenda que isto seja feito pelo usuário final.

E se não recomenda, porque então oferecer a atualização na tela ou no display do aparelho?

Porque isto é automático. Dentro de cada aparelho com este tipo de recurso, uma vez conectado à Internet, ele roda um programa de acesso ao servidor da fábrica, que examina a versão do firmware do equipamento e a compara com a versão atual. Se não baterem na numeração, a mensagem é exibida. Notem que todo firmware tem uma data fixa em cada “release”, sendo então impossível haver confusão nas versões.

Idealmente, a atualização on-line deveria ser feita com a ajuda de um no-break (UPS), de modo a evitar o perigo de falta de luz durante o processo. Ou, se o usuário não confia em sua rede local ou provedor, ele deve baixar antes a atualização e copia-la para um drive USB, caso haja previsão para o mesmo.

Uma atualização mal feita ou interrompida pode tornar o equipamento inoperante. Mas este é um problema que, diga-se de passagem, já deveria ter sido corrigido. Na minha última montagem do computador pessoal, o fabricante da placa mãe previu isso. Se der zebra no processo de atualização, por qualquer motivo, usa-se um disco fornecido com a placa, que recupera o firmware (BIOS) original. Outros fabricantes oferecem placas com duplo circuito para o firmware, um deles com a cópia do original. Se falhar um, o outro entra em ação, impedindo que a placa pare de funcionar.

Nos celulares e similares

Se fosse feito um concurso de campeonato de erros de programação, o telefone celular ganhava batido. E volta e meia, é preciso desligar o aparelho completamente, aguardar um pouco e liga-lo de volta. Com sorte, o erro desaparece. Via-de-regra, um erro qualquer de processamento, derivado de aplicativos, vai ficar provisoriamente residente na memória volátil do celular. Desligando-se o mesmo, a memória apaga e o ele volta ao “normal”.

E como tentar evitar isso, dentro do possível? Aceitando as ofertas de atualização, em primeiro lugar. Com o número cada vez maior de aplicativos, não é surpresa o usuário ser notificado sobre as atualizações constantemente.

Em alguns casos, onde a recuperação não é possível, o fabricante oferece um software on-line de recuperação. Se o usuário for precavido, ele ou ela fazem uma cópia de segurança dos dados do telefone, que podem depois serem usados para restaurar o aparelho às suas informações de origem.

Em qualquer hipótese o usuário final tem que ter atenção dobrada com o seu telefone. Com a premência cada vez maior do uso do celular em transações bancárias, por exemplo, a não atualização dos aplicativos pode acabar resultando na inadimplência de acesso à conta do banco.

Em sistemas operacionais de várias plataformas, os erros de programação são virtualmente inevitáveis e muitos deles tornam o sistema vulnerável a ataques, coisa que acontece constantemente em ambientes como o do Windows.

Na tentativa de evitar pelo menos ataques resultantes de acessos a determinados sites, alguns roteadores já possuem um programa anti-malware instalado no hardware, e avisa ao usuário quando um site malicioso está na lista negra do programa.

Tornar um sistema operacional mais seguro, seja nos computadores, TVs, celulares ou tablets, é hoje mandatório, diante de uma Internet usada para fins malignos, e absolutamente ninguém está isento de ser atingido. Portanto, a regra é atualizar tudo, principalmente programas de proteção. Pode não acabar com o problema, mas diminui os riscos substancialmente.  Outrolado_

 

Leia também

 

A evolução da rede local doméstica

 

Por que o micro de 8 bits foi tão importante

Paulo Roberto Elias é professor e pesquisador em ciências da saúde, Mestre em Ciência (M.Sc.) pelo Departamento de Bioquímica, do Instituto de Química da UFRJ, e Ph.D. em Bioquímica, pela Cardiff University, no Reino Unido.

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on telegram
Share on pocket

Mais lidas

0 resposta

  1. Paulo,

    Sou analista de suporte/programador desde 1977 e tive o privilégio de viver (na pele) muitas mudanças que aconteceram no “processamento de dados” (naquela época não se falava “informática”, pelo menos no meio comercial). Como (quase) todos, naqueles dias começávamos aprendendo Fortran e, no meio comercial, COBOL. Por ter enveredado para a área de suporte já no começo da minha carreira, o assembler (Basic Assembly Lamguage) da IBM (sempre trabalhei com IBM mainframe) me foi obrigatório de me encantei totalmente com essa linguagem tanto que passei quase toda a minha carreira como programador assembler. Atualmente estou fazendo um curso de “Machine Learning” (trabalho numa empresa de energia elétrica) e, através do noticiário, notei que as aplicações dessa disciplina, mesmo sendo muito bem implementadas, não foram assimiladas pelos usuários. Quando da popularização da computação, através do PC (personal computer, não o partido), as pessoas se familiarizaram com o “cérebro eletrônico” e descobriram que a maioria dos problemas vinham de má programação. Criou-se um paradigma de infalibilidade do computador versus a falibilidade do programador. Atualmente, com as aplicaçãoes de inteligência artificial, esse paradigma está dando um nó na cabeça dos usuários em geral: porque os sistemas de IA são “falhos”? Creio que por costume (e doutrinação), se o computador não falha a margem de erro estabelecida nos sistemas de IA (90% de acerto para identificação facial, por exemplo) deve ser, necessariamente, erro de programação. Me parece que é assim o raciocínio do usuário. Algumas semanas atrás li um artigo na BBC no qual, em Inglaterra, um hospital reclamou que o sistema que faz diagnósticos, estava errando. Creio que esse paradigma (“computador não erra”) é o desafio para as novas gerações de cientistas de informática.

    1. Oi, Wandique,

      O meu irmão, hoje aposentado, também trabalhou na sua área, e também passou por poucas e boas, no contato com o usuário final, ao qual ele volta e meia dava suporte. Algumas dessas estórias viraram anedotas, você entende por quê.

      Eu quero te dizer que tenho grande admiração pelos programadores que têm habilidade de escrever programas em Assembly. Na época das máquinas de 8 bits eu tive a chance de conhecer gente muito jovem fazendo miséria, em computadores notoriamente limitados. Infelizmente, não sei o que foi feito deles, mas sempre que lembro desta época, fico torcendo que eles tenham tido sucesso na vida profissional.

      1. Paulo,

        Éramos caçadores de dinossauros (ou os próprios). A programação, com o advento do processamento distribuído, sofreu uma mudança avassaladora, de modo que atualmente o programador precisa de ajuda externa e conta com múltiplas bibliotecas com funções “prontas”. Não sou contra o reaproveitamento de código mas sempre fico desconfiado de que sempre pode haver back-doors nessas funções. Pode ser paranóia mas sempre existe essa possibilidade. Creio que são sequelas da guerra fria.

        1. Concordo totalmente contigo! Agora, quando eu fazia programação não era incomum aproveitar rotinas de terceiros, eu acho que você passou por isso também. Foi, acho eu, um mal necessário naquele momento. Eu consegui me safar disso em alguns momentos, quando por exemplo eu criei rotinas para tratamento estatístico dos dados do laboratório, MAS ao meu lado esteve um colega mais senior, que sabia estatística a fundo e zero de programação. Ele me dava o algoritmo tradicional e eu ficava horas (eu sou lento mesmo…) bolando uma rotina para fazer aquilo tudo que ele me explicava.

          A propósito, eu sofri críticas na minha defesa de tese de mestrado, feitas por um pesquisador da Fiocruz, que disse ter sido um “exagêro” tratar meus dados com a ajuda de programas, e arrematou me dizendo que ele conseguia fazer tudo aquilo com uma (pasme) calculadora de bolso. O meu irmão assisitiu a defesa e saiu de lá revoltado com aquela crítica. Mas, a comunidade acadêmica sempre deu sinais de tecnofobia, não só naquela época (final da década de 1970) como nos anos seguintes, quando a microinformática começou a tomar corpo.

  2. Paulo,

    Sou analista de suporte/programador desde 1977 e tive o privilégio de viver (na pele) muitas mudanças que aconteceram no “processamento de dados” (naquela época não se falava “informática”, pelo menos no meio comercial). Como (quase) todos, naqueles dias começávamos aprendendo Fortran e, no meio comercial, COBOL. Por ter enveredado para a área de suporte já no começo da minha carreira, o assembler (Basic Assembly Lamguage) da IBM (sempre trabalhei com IBM mainframe) me foi obrigatório de me encantei totalmente com essa linguagem tanto que passei quase toda a minha carreira como programador assembler. Atualmente estou fazendo um curso de “Machine Learning” (trabalho numa empresa de energia elétrica) e, através do noticiário, notei que as aplicações dessa disciplina, mesmo sendo muito bem implementadas, não foram assimiladas pelos usuários. Quando da popularização da computação, através do PC (personal computer, não o partido), as pessoas se familiarizaram com o “cérebro eletrônico” e descobriram que a maioria dos problemas vinham de má programação. Criou-se um paradigma de infalibilidade do computador versus a falibilidade do programador. Atualmente, com as aplicaçãoes de inteligência artificial, esse paradigma está dando um nó na cabeça dos usuários em geral: porque os sistemas de IA são “falhos”? Creio que por costume (e doutrinação), se o computador não falha a margem de erro estabelecida nos sistemas de IA (90% de acerto para identificação facial, por exemplo) deve ser, necessariamente, erro de programação. Me parece que é assim o raciocínio do usuário. Algumas semanas atrás li um artigo na BBC no qual, em Inglaterra, um hospital reclamou que o sistema que faz diagnósticos, estava errando. Creio que esse paradigma (“computador não erra”) é o desafio para as novas gerações de cientistas de informática.

    1. Oi, Wandique,

      O meu irmão, hoje aposentado, também trabalhou na sua área, e também passou por poucas e boas, no contato com o usuário final, ao qual ele volta e meia dava suporte. Algumas dessas estórias viraram anedotas, você entende por quê.

      Eu quero te dizer que tenho grande admiração pelos programadores que têm habilidade de escrever programas em Assembly. Na época das máquinas de 8 bits eu tive a chance de conhecer gente muito jovem fazendo miséria, em computadores notoriamente limitados. Infelizmente, não sei o que foi feito deles, mas sempre que lembro desta época, fico torcendo que eles tenham tido sucesso na vida profissional.

      1. Paulo,

        Éramos caçadores de dinossauros (ou os próprios). A programação, com o advento do processamento distribuído, sofreu uma mudança avassaladora, de modo que atualmente o programador precisa de ajuda externa e conta com múltiplas bibliotecas com funções “prontas”. Não sou contra o reaproveitamento de código mas sempre fico desconfiado de que sempre pode haver back-doors nessas funções. Pode ser paranóia mas sempre existe essa possibilidade. Creio que são sequelas da guerra fria.

        1. Concordo totalmente contigo! Agora, quando eu fazia programação não era incomum aproveitar rotinas de terceiros, eu acho que você passou por isso também. Foi, acho eu, um mal necessário naquele momento. Eu consegui me safar disso em alguns momentos, quando por exemplo eu criei rotinas para tratamento estatístico dos dados do laboratório, MAS ao meu lado esteve um colega mais senior, que sabia estatística a fundo e zero de programação. Ele me dava o algoritmo tradicional e eu ficava horas (eu sou lento mesmo…) bolando uma rotina para fazer aquilo tudo que ele me explicava.

          A propósito, eu sofri críticas na minha defesa de tese de mestrado, feitas por um pesquisador da Fiocruz, que disse ter sido um “exagêro” tratar meus dados com a ajuda de programas, e arrematou me dizendo que ele conseguia fazer tudo aquilo com uma (pasme) calculadora de bolso. O meu irmão assisitiu a defesa e saiu de lá revoltado com aquela crítica. Mas, a comunidade acadêmica sempre deu sinais de tecnofobia, não só naquela época (final da década de 1970) como nos anos seguintes, quando a microinformática começou a tomar corpo.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *