Resolvendo erros de software

Seu sistema começou a apresentar problemas? Estas dicas podem lhe ajudar a resolvê-los.

Você começou a desenvolver um projeto e até agora tudo normal; os módulos trabalham corretamente, a aplicação está funcionando e o servidor de desenvolvimento responde perfeitamente as requisições. Ao final do dia você faz uma atualização em alguns módulos e páginas, atualiza seu servidor de versionamento e desliga sua máquina, já preparando o espírito para o final de semana que promete.

Na segunda-feira retornando com aquela ressaca, liga o computador para começar a trabalhar e o projeto que deixou no último dia não mais funciona. Diversas mensagens de erro na tela dos mais diferentes tipos e você com a obrigação de entregar o resultado dentro de dois dias. O desespero bate a sua porta e vem aquela vontade de chutar tudo e se mudar para o Nepal. Então, o que fazer?

1º passo – Calma

Esta é a primeira dica. Você não conseguirá resolver o(s) problema(s) de cabeça quente (e com ressaca menos ainda), podendo piorar ainda mais o filme de terror que passa diante de seus olhos. Os minutos que gastará respirando fundo e se acalmando são compensados com uma solução rápida para a situação. A calma também serve para prepará-lo para os próximos passos na solução do problema.

2º passo – Entender o problema

Depois que se acalmar, é preciso entender o problema que está enfrentando. É um problema de acesso ao banco de dados? É uma mensagem de erro ou somente um “notice”? É uma tela branca ou seus arquivos desapareceram?

Entender o problema é certamente mais da metade da solução. Muitos desenvolvedores iniciantes (e até mesmo experientes) batem cabeça por horas a fio tentando diferentes soluções porque não pararam para compreender a situação e esquecem de ler com calma (olhe ela ai novamente) as mensagens de erro ou possuem dificuldade na interpretação, seja pelo idioma (inglês na maior parte das vezes), seja porque não estão acostumados. Não importa; entender o problema é o primeiro passo.

Um exemplo para fácil da importância de entender o problema é quando acaba o espaço de armazenamento em disco. Sem espaço, muitas das tarefas que precisam ser realizadas não acontecem e o sistema “trava”. Este não é um cenário para restauração de um backup por exemplo, mas sim para, de alguma forma, conseguir espaço para que o sistema volte a funcionar. O entendimento está na compreensão de que o problema (travamento) do sistema está sendo ocasionado pela falta de espaço em disco e não pelo sistema em si. Sem este entendimento, se perde tempo na caça ao problema do sistema quando na verdade ele está no hardware.

O entendimento também é importante para avaliar se existe realmente um problema. Muitas vezes o desenvolvedor é induzido ao erro de acreditar que existe um problema, quando ele realmente não existe. Exemplo clássico desta situação é o cache dos navegadores. Esquecendo-se de eliminar aquilo que está armazenado pode induzir ao erro quando está se criando, por exemplo, um tema gráfico.

3º passo – Avaliar o problema

Existem problemas e “problemas” e você precisa descobrir qual o nível de severidade daquele que está enfrentando. Um “grande problema” como a falência de um disco rígido pode se tornar pequeno se você tiver uma boa política de backup de dados onde bastará um restore num disco novo para ele ser resolvido. Porém um “pequeno problema” como a diferença de fuso horário pode se tornar enorme se você tem processos que precisam ser executados em horários específicos.

Esta avaliação irá ajudá-lo na tomada de decisão e principalmente em sua sequencia. É mais frutífero (e rápido) restaurar um backup ou procurar a solução na Internet (ferramentas de busca, fóruns, listas, etc)? É mais fácil trocar uma parte do hardware ou levar todo o sistema para outra máquina? Dependendo de quão severo é o problema, sua decisão pode ser alterada ou não.

4º passo – Solucionar o problema

Depois de se acalmar, avaliar e entender o problema, é hora de solucioná-lo, seja da forma que for. Para alguns, uma simples limpeza no cache resolve. Para outros e em casos extremos, começar do zero é o melhor (o que não deixa de ser uma solução, convenhamos).

A solução varia de acordo com o problema e não seria possível listar todos aqueles que podem surgir em sua frente. O importante neste passo é procurar uma solução que realmente resolva o problema utilizando os passos anteriores e calma, entendimento e avaliação. Com isso a solução pode estar muito mais próxima que imagina.

5º passo – Documentar o problema

Este é o passo que a esmagadora maioria esquece de fazer, seja por preguiça, por falta de tempo, de organização ou simplesmente porque não quer fazer (existe também o caso daqueles que acreditam que nunca mais se repetirá). Entretanto a documentação de um problema pode auxiliá-lo na resolução de problemas recorrentes ou mesmo similares, oferecendo pistas sobre o que pode esta acontecendo numa nova situação.

Alguns mantém um “dicionário de problemas” num arquivo-texto, num wiki ou mesmo num blog (tenho um amigo que anota os problemas numa moleskine e anda sempre com ela). Não importa o método, o local (desde que seja acessível) ou o meio. O que realmente importa é documentar as informações do problema, o ambiente onde ele ocorreu e as informações da solução. Com isso se pode manter uma base de conhecimento mínima para uso futuro.

Meu método é usar um wiki privado onde mantenho todos os erros que encontro ao longo do trabalho em meus projetos. Nele possuo uma tabela como as seguintes colunas:

• Projeto → nome do projeto onde apareceu o erro;
• Erro → qual o tipo de erro (tela branca, travamento, mensagem de erro, etc);
• Mensagem → se existiu uma mensagem de erro na tela ou no log, copio ela aqui;
• Solução → qual a solução que encontrei para o erro, contendo os passos executados para resolver o problema;
• Ambiente → em qual ambiente deu-se o problema (hardware, sistema operacional, versões, etc);
• Data → a data do problema;

Esta tabela é minha primeira fonte de consulta quando surge uma nova situação catastrófica. Antes de consultá-la não vou ao Google, à fóruns de discussão ou mesmo às listas de e-mails pois, se já passei por situação igual ou similar, a resposta pode ser mais rápida.

A documentação também tem uma outra faceta interessante que é a ajuda à comunidade. Se trabalha com software livre ou mesmo com linguagens não livres, seu suporte é principalmente realizado por outros usuários que colaborativamente compartilham conhecimento e pesquisa e solução de problemas é, sem dúvida nenhuma, uma forma de conhecimento. Assim, se você passa por uma situação e a mantém documentada, é fácil depois compartilhar este conhecimento com outras pessoas que podem passar pela mesma situação.

Problemas em software são tão corriqueiros quanto chuva no verão e certamente irá acontecer com você também. A diferença está em como abordar o problema e como solucioná-lo, seja ele pequeno ou grande.