O assunto deste post não requer nenhuma experiência com programação para ser entendido. Porém, faz diferença em todas as fases da carreira de um desenvolvedor.
Alguns detalhes simples são capazes de mudar muita coisa (para melhor ou para pior) na vida do usuário e da própria equipe. Mensagens de erro são uma delas.
Quem nunca recebeu de um sistema mensagens como: “Ocorreu um erro!” ou “Não foi possível concluir!“.
Pior ainda é quando aparece uma mensagem cheia de códigos técnicos, incompreensíveis a usuários leigos.
Ora! Falando como desenvolvedor, pense comigo: Qual a utilidade dessas mensagens? O que elas agregam à vida do usuário além de uma péssima notícia?
Existem sim alguns casos – específicos e raros – onde um erro genérico e imprevisível acontece. Geralmente isto está ligado a quedas de conexão ou incidentes ocorrendo em pleno run-time.
Mas na maioria dos casos é possível apresentar uma mensagem decente. E você, como um bom desenvolvedor(a) deve fazer isso.
Eu costumo usar uma regra de bolso, segundo a qual qualquer mensagem de erro deve conter:
- O que aconteceu de errado;
- O que o usuário pode fazer para corrigir, nem que seja “contatar o administrador do sistema“.
Então, teríamos um template como: <Aconteceu isto aqui.> <Por favor, tente resolver dessa forma.>
Exemplo: Campo Nome está vazio. Por favor, preencha todos os campos marcados como obrigatórios.
Adicionalmente, podemos usar ícones e cores para diferenciar visualmente mensagens com severidades diferentes. Mas isso é assunto para outro artigo.
Como eu dizia no início, coisas simples fazem (muita) diferença, inclusive no reconhecimento que você recebe pelo seu trabalho.
Ao longo dos 20 anos que eu dediquei à programação (comecei a programar aos 12!), fui colecionando vários desses templates para otimizar meu trabalho. Não só em coisas tão simples quanto essas mensagens de sistema…
Em certo momento da minha carreira, a maior parte do meu trabalho passou a ser organizar esses macetes mentais para saber qual aplicar em cada tarefa (em vez de sair programando tudo sempre do zero como eu fazia antes).
A partir daí comecei a ser muito, mas muito reconhecido pelo meu trabalho como desenvolvedor – por usuários, colegas, chefes e até diretores.
O caso das mensagens de erro foi só um exemplo para chamar sua atenção à importância de pensar constantemente em boas práticas e padrões. Esse exemplo é legal por ser bastante concreto, mas o princípio vale para muitas outras coisas – abstratas e maiores – como CRUDs, usabilidade, relatórios, controle de acessos, etc.
Tais coisas não precisam ser discutidas com a equipe ou com o gerente de projetos. Elas fazem parte do jeito de programar do profissional.
Felizmente, eu consegui dedicar um tempo da minha vida para focar em estruturar um material com todos os templates, boas práticas, padrões e check-lists que eu aprendi ao longo da minha carreira. Inclusive com desenvolvedores melhores do que eu.
Dessa ideia nasceu o livro Como ser um desenvolvedor acima da média, que eu publiquei este ano. Se você, dev, estiver interessado(a) em decolar na sua carreira, confira e aproveite! Vai ser um prazer lhe ajudar!
André Aranha
Desenvolvedor e arquiteto de software | MCP | PMP | PSM | PSPO. Graduado em Sistemas de Informação pelo Mackenzie e pós graduado em Gerenciamento de Projetos pela FIAP.
Autor do livro Como ser um desenvolvedor acima da média.