Dicas para o desenvolvimento de um software Parte 7

Prévia do material em texto

andrecelestino.com
Dicas para o desenvolvimento de um software - Parte 7
Ver todos os artigos de André L. Celestino →
Opa! Estou de volta com a sétima parte sobre dicas de desenvolvimento de software! Nesse artigo,
continuo tratando de alguns pequenos “ajustes” no software, mas que fazem diferença para o usuário.
Afinal, é ele quem convive diariamente com o produto do nosso trabalho. Lembre-se de que um bom
desenvolvimento certamente garante uma boa satisfação.
Submenus infinitos
Imagine que o usuário tenha que acessar 5 submenus para emitir um relatório?
Até ele chegar no último submenu já acabou o expediente, rsrs.
Recomenda-se que um menu tenha, no máximo, 2 submenus. Mais do que isso pode atrapalhar o acesso à
tela ou funcionalidade, além de confundir as opções em meio a tantos itens. É comum encontrar também
submenus desnecessários, como a seleção da impressora para imprimir um relatório. No meu ponto de
vista, essa opção pode ser adequadamente incluída na própria tela de visualização do relatório ou no
diálogo de impressão.
Uma alternativa é criar uma barra de ferramentas com botões de acesso para as telas mais utilizadas,
evitando que o usuário tenha que percorrer vários submenus para abri-las. Essa alternativa torna-se ainda
melhor se a barra de ferramentas for personalizável, ou seja, permitir que o próprio usuário escolha os
botões que ficarão disponíveis na barra. Estes atalhos são muito úteis em sistemas que integram dois ou
mais departamentos de uma empresa, já que em cada departamento as telas acessadas com mais
frequência são diferentes.
Assim como comentei na primeira parte dessa série de artigos, alguns softwares mais modernos
apresentam menus do tipo Ribbon, parecidos com as versões mais recentes do Microsoft Office. Esse tipo
de menu, por possuir abas e botões de opção, podem facilmente substituir os menus tradicionais de um
sistema e apresentar uma navegação mais intuitiva.
Dicas para o desenvolvimento de um software - Parte 7 about:reader?url=http://www.andrecelestino.com/dicas-para-o-desenvo...
1 de 4 20/03/2017 09:23
Formato da data e valores
Essa é clássica! Há muitos softwares por aí que exibem datas no formato americano (mês/dia/ano) e
confundem a cabeça do pobre cidadão. Quando o usuário encontra a data “12/15/2013”, além de tentar
interpretá-la, normalmente ele toma uma atitude: reclama do sistema ou liga para o suporte.
Há um grande risco quando a data se parece comum, como, por exemplo, o dia “03/06/2013” ser exibido
como “06/03/2013”. Embora esteja errada, o usuário pode interpretá-la como o dia 06 de março. Se o
sistema trabalhar com históricos, movimentações ou agendamentos, essas datas podem trazer sérios
problemas!
Isso também vale para formatos de valores monetários. Procure sempre manter o ponto como separador
de milhares e a vírgula como separador decimal. Caso o banco de dados exija que o armazenamento seja no
formato americano, cabe ao software realizar a conversão necessária para gravar e exibir corretamente os
valores.
No Delphi, pode-se adicionar as linhas abaixo no arquivo DPROJ (ou DPR, nas versões antigas) para
garantir essa padronização em qualquer ambiente Windows em que o software for executado:
FormatSettings.ThousandSeparator := '.';
FormatSettings.CurrencyFormat := 2;
FormatSettings.DecimalSeparator := ',';
FormatSettings.ShortDateFormat := 'dd/mm/yyyy';
FormatSettings.DateSeparator := '/';
Mensagens em excesso
As mensagens acima são irônicas, mas na realidade alguns sistemas parecem fazer uma entrevista com o
usuário: para qualquer operação existe uma tela de confirmação, até para as operações mais rotineiras.
Mensagens são necessárias, mas não em excesso. Há operações que são óbvias, e não precisam ter uma
mensagem de informação ou confirmação para serem realizadas. É claro que isso não irá afetar o
desempenho do software, mas já me deparei com muitos usuários que solicitaram a remoção de algumas
mensagens pelo motivo de atrapalhar a usabilidade.
Se a intenção é exibir uma mensagem informativa, considere exibi-la no formulário de forma estática,
utilizando uma Label, por exemplo. Mensagens de validação também podem ser substituídas por balões
com hints (hint balloons) que, além de não exigir interação do usuário (para pressionar o OK), também são
Dicas para o desenvolvimento de um software - Parte 7 about:reader?url=http://www.andrecelestino.com/dicas-para-o-desenvo...
2 de 4 20/03/2017 09:23
bem modernos.
Só para complementar, já trabalhei com sistemas que não exibem mensagem alguma ao gravar um
registro, apenas limpam os campos para a inserção de novos dados. Se for uma tela que permite inserções
sucessivas, essa modalidade pode ser bem adequada. Basta orientar o usuário de que, se o sistema “limpar”
o conteúdo dos campos ao gravar o registro, significa que foi gravado com sucesso.
Gravação de imagens no banco de dados
Nos fóruns de programação é comum encontrar dúvidas relacionadas à gravação de imagens em tabelas no
banco de dados. Bom, antes de implementar essa função no seu sistema, lembre-se de que os dados
binários das imagens são extensos e podem sobrecarregar o banco de dados. Para compreender melhor,
acompanhe a prática: imagine que você tenha um cadastro de clientes que permita associar uma foto do
cliente ao registro. Em um dos cadastros, o usuário carrega uma imagem no formato BMP de 2MB.
Imagem grande, não é? Pois bem, ao gravá-la no banco de dados, significa que estes 2MB serão inseridos
na tabela. Portanto, se o usuário repetir essa operação para os próximos 100 clientes, o banco de dados
armazenará 200MB somente com as imagens! Além de pesar o banco de dados, isso pode afetar o tempo
de retorno dos dados ao consultar o registro, já que o banco de dados irá selecionar todo o conjunto
binário referente à imagem e trazer para a aplicação. Considere também que no caso de uma aplicação
cliente/servidor, essa consulta pode ainda congestionar o tráfego na rede.
Oras, basta controlar o tamanho da imagem a ser carregada, como por exemplo, somente imagens JPG
com tamanho menor que 50KB!
Certo, essa é uma alternativa, mas mesmo assim ainda tenho três argumentos:
1) Não deixa de ser uma imagem, então ela terá que ser gravada em um campo de um tipo especial na
tabela, como o BLOB do Firebird;
2) Você terá que implementar um código específico tanto para a gravação quanto para a leitura da
imagem;
3) E o mais impactante: o usuário terá que utilizar um aplicativo externo para redimensionar e converter a
imagem para que atenda os requisitos da sua aplicação. Para muitos, isso pode se tornar entediante.
O que você sugere então, infeliz?
Na verdade, eu já me deparei com a necessidade de armazenar imagens no banco de dados e realmente fui
infeliz, rsrs. A solução que encontrei (na qual é a solução que muitos desenvolvedores adotam) é copiar a
imagem para uma subpasta dentro do diretório da aplicação. Por exemplo, pode-se criar uma pasta
chamada “Imagens” e ao carregar uma foto do cliente na aplicação, você simplesmente copia o arquivo
para dentro dessa pasta ao invés de gravar a imagem no banco de dados. Para ler a imagem é ainda mais
simples: basta carregar o arquivo que está na pasta!
Mas… e se o arquivo já existir nessa pasta?
Simples! Durante a cópia, você pode renomear o arquivo conforme algum dado que identifique o cliente,
como o próprio código. Por exemplo, no cadastro do cliente nº 10, o usuário irá carregar o arquivo
“Andre.jpg” na aplicação, mas este arquivo será salvo como “00010.jpg” dentro da pasta de imagens. Bom,
então já deu pra perceber que pra fazer a leitura será bem fácil, não é? Basta carregar a imagem que tenha
Dicas para o desenvolvimento de um software - Parte 7 about:reader?url=http://www.andrecelestino.com/dicas-para-o-desenvo...
3de 4 20/03/2017 09:23
o nome igual ao código do cliente selecionado.
No Delphi, é possível copiar o arquivo da seguinte forma:
var
 ImagemOrigem: string;
 ImagemDestino: string;
begin
// este arquivo pode ser selecionado com um TOpenDialog
 ImagemOrigem := 'C:\Clientes\Fotos\Andre.jpg';
 
// o nome da imagem de destino será "00010.jpg"
 ImagemDestino := 'C:\Aplicativo\Imagens\' + CodigoCliente + '.jpg';
 
 CopyFile(PChar(ImagemOrigem), PChar(ImagemDestino), False);
end;
E por fim, para carregar:
Image1.Picture.LoadFromFile('C:\Aplicativo\Imagens\' + CodigoCliente +
'.jpg');
Pessoal, caso queiram sugerir ideias ou discutir algo, deixe um comentário ou entre em contato.
Obrigado novamente!
Confira também as outras partes deste artigo:
Dicas para o desenvolvimento de um software – Parte 1
Dicas para o desenvolvimento de um software – Parte 2
Dicas para o desenvolvimento de um software – Parte 3
Dicas para o desenvolvimento de um software – Parte 4
Dicas para o desenvolvimento de um software – Parte 5
Dicas para o desenvolvimento de um software – Parte 6
Dicas para o desenvolvimento de um software – Parte 7
Dicas para o desenvolvimento de um software – Parte 8
Dicas para o desenvolvimento de um software – Parte 9
Dicas para o desenvolvimento de um software – Parte 10
Dicas para o desenvolvimento de um software – Parte 11
Dicas para o desenvolvimento de um software - Parte 7 about:reader?url=http://www.andrecelestino.com/dicas-para-o-desenvo...
4 de 4 20/03/2017 09:23