Quando o compilador atrapalha

É um erro o desenvolvedor confiar que um programa vai funcionar bem apenas porque o compilador não apontou falhas.

Por Handerson Ferreira Gomes

No recanto do escritório, todos os dias, aquele programador trava uma luta contra um compilador – nem sempre sangrenta, nem sempre silenciosa, mas quase sempre sofrida. Usando os mais incríveis e inimagináveis recursos (apagar linhas, compilar com parâmetros, jogar água benta sobre os teclados) ele tenta vencer o compilador que insiste em não compilar aquele programa.

Depois de algumas dezenas de minutos ele descobre o erro: um comando de sintaxe inválido ou uma biblioteca que faltava no CLASSPATH.

A prática é muito comum hoje em dia e, no meu ponto de vista, um dos principais problemas do desenvolvimento de software – um programa não deve ser feito apenas para compilar e sim para funcionar! É preciso uma mudança de comportamento dosdesenvolvedores mais jovens, que acreditam que após passar pelo compilador o programa está terminado e irá funcionar.

Os compiladores mais modernos são bastante eficazes – mostram nitidamente onde está o erro, sugerem correções e outros recursos. As ferramentas gráficas de desenvolvimento possuem ótimos recursos para depuração e edição. Mas ainda assim há programadores que perdem a visão geral, que deveria ser a solução de problemas, e acabam focando apenas em conseguir compilar com sucesso seu código fonte.

Não tenho nada contra as ferramentas visuais de criação de interfaces; pelo contrário, acho de extrema importância quando bem usadas. Porém, o que tenho visto no mercado é que os programadores, principalmente os iniciantes, deslumbrados com a facilidade de mover objetos como botões, janelas e rótulos pela tela, acabam esquecendo o principal objetivo de um programa: receber dados, processar e retornar um resultado correto.

É comum encontrar programadores que escrevem a primeira linha de código sem ter a menor idéia do que vai ser escrito nas próximas 20 linhas, qual estrutura será utilizada, como o programa deve ser comportar e quais os outros programas envolvidos no processo. A fase de planejamento é crucial para o sucesso de um programa, principalmente nos quesitos prazo e qualidade.

Imagine uma casa sendo construída sem uma planta: a partir de um terreno vazio aconstrução começaria pela sala, pois é o centro da casa. Depois seriam anexadas portas para os quartos, porta para a cozinha, porta para a área de serviço outra para a varanda. Puxa, esqueceram da janela da sala.

Tudo bem, coloca em cima da porta, fica bonito assim… bem moderno! Quando é iniciado a construção dos quartos, percebe–se que a sala ficou com muitas portas e é preciso colocar um corredor para acesso aos quartos e deixar a sala mais clean. Tudo bem, faz–se uma nova parede, que será o corredor. Agora a sala ficou pequena. Sem problemas, nomeia a sala atual de sala íntima e constrói um segundo piso onde vai ter a sala de jantar, é até melhor que fica bem dividido. Será que o alicerce vai suportar um segundo piso? Claro….

Além de não fazer um plano de desenvolvimento, algo como um algoritmo, algunsprogramadores também não têm o costume de fazer testes de mesa após o término do programa. E este é um outro ponto de extrema importância.

Eu ainda jogava golzinho na rua, com pés descalços e sandálias havaianas como trave, quando as universidades recebiam os primeiros computadores. Naquele tempo toda a codificação era feita manualmente em pequenas cartões perfurados e só depois de pegar uma fila de horas ou dias de agenda era possível compilar e executar o seu programa, pois eram raros os computadores para todo o campus. Se houvesse algum erro, seja de sintaxe ou lógica, o programador teria que esperar mais alguns dias para ter a chance de compilar novamente o seu trabalho. Para evitar todo tipo de erro os programas eram verificados mais de uma vez, passavam N vezes pelo teste de mesa e chegavam com 99% de chance de funcionar.

Por que será que na década de 60 o homem já estava colocando os pés na lua enquanto hoje alguns robôs de milhares de dólares estão perdidos na superfície marciana? Com certeza temos hoje muito mais tecnologia do que em meados de 60 e 70. A diferença é que naquela época os cientistas confiavam menos em seus cálculos e por isso mesmo eram maiscriteriosos.

Não se trata de um problema técnico e sim comportamental. Os desenvolvedores de software precisam entender que um bom programador não é aquele que faz códigos complexos ou usa uma API mais moderna. O mais importante é que o programa resolva os problemas para o qual ele está sendo desenvolvido e, sempre que possível, de forma elegante.

Mas nem sempre a culpa é dos programadores, e geralmente não é. O cronograma apertado dos projetos, a quantidade desumana de horas de trabalho e a pressão das várias áreas de negócio fazem com que o programador acabe sendo obrigado a pular algumas das etapas importantes do desenvolvimento de software para entregar o código dentro do cronograma, que algumas vezes é feito sem consultá–lo.

Todo este artigo pode parecer muito óbvio, mas infelizmente o mercado está cheio de programadores de telas e precisando de programadores funcionais.

No próximo artigo vamos discutir um pouco mais sobre o planejamento de software, dando dicas práticas de como melhorar esta atividade essencial para o sucesso do seu programa, mesmo que ele tenha apenas 50 linhas de código.

Um erro de programação que custou muito caro

A agência espacial americana NASA perdeu em 1999 a nave espacial Mars Climate Orbiter por causa de uma simples confusão entre números expressos em unidades diferentes. Uma, no Sistema Métrico Decimal (que usa metro e quilograma) e outra, em unidades britânicas (que usam pé e libra).

As informações eram consideradas críticas para que a sonda alcançasse a órbita apropriada de Marte. O acumular de erros de cálculo fez com que a nave ao chegar a Marte se tivesse desviado mais de 100 km da trajetória prevista, desfazendo–se na atmosfera de Marte (a margem de segurança era de 75 km).

Não só os técnicos da NASA não se aperceberam do erro ao introduzir os dados no computador para fazer os cálculos relativos ao controle dos motores, como, além do mais, não tinham elementos verificadores dos resultados obtidos: desde que partiu da Terra a nave espacial esteve sempre numa posição diferente daquela calculada pelos técnicos; numa viagem de 700 milhões de quilômetros e de vários meses a nave espacial ia ficando cada vez mais afastada da órbita necessária e ninguém percebeu isso! [web insider]

1 pessoa comentou o artigo "Quando o compilador atrapalha"

Avisos

Os ítens com asterisco ( * ) são campos de preenchimento obrigatório.

Todos os links inseridos nos comentários possuem o atributo rel="nofollow" para impedir com que user agents (como os mecanismos de busca) sigam os links inseridos para desestimular spammers.

Todos devem se identificar através de e-mail válido.

Os e-mails dos usuários não serão divulgados no site.