Dicas para o desenvolvimento de um software funcional – Parte X

Olá, leitores.

A décima parte da série sobre dicas para um desenvolvimento de um software traz uma abordagem mais pragmática relacionada às características funcionais de uma aplicação. Aproveito para agradecer aos leitores que acompanharam e divulgaram os outros artigos dessa série (leia: Parte 1, Parte 2, Parte 3, Parte 4, Parte 5, Parte 6, Parte 7, Parte 8, Parte 9).

Alinhamento dos componentes da tela

Recentemente, recebi um e-mail de um desenvolvedor que encontrou problemas ao executar a aplicação em computadores com diferentes resoluções. Segundo ele, quando a resolução era mais alta, os componentes ficavam todos bagunçados na tela do usuário. Para que eu pudesse ajudá-lo, ele também me enviou um código que realizava o redimensionamento automático dos componentes conforme a resolução do computador. Essa é uma opção, mas, no meu ponto de vista, optar pelo alinhamento é melhor.

Alinhar os componentes na tela significa fixá-los em determinadas áreas. Por exemplo, o painel de pesquisa pode ser alinhado no topo da tela, a Grid de dados no centro e o painel de botões na parte inferior. Ao alterar o tamanho da tela, os componentes acompanharão o redimensionamento de forma que continuem corretamente distribuídos, sem necessariamente sofrer alterações no próprio tamanho. Em outras palavras, se o painel de botões está alinhado à parte inferior central (bottom-center), ele continuará no centro independente do tamanho da tela.

Por outro lado, nada impede que o desenvolvedor limite o redimensionamento das telas da aplicação, configurando os parâmetros mínimo e máximo de altura e largura. Essa configuração evita que o visual de uma tela fique comprometido quando houver um redimensionamento fora do padrão.

Espaços em branco

Você conhece aquele tipo de usuário que coloca um, dois ou até três espaços em branco antes de começar a digitar? Acredito que sim! Apesar de desconhecidas pelos usuários, os espaços em branco no início de um campo em um registro podem trazer algumas consequências. A primeira delas é a questão da consulta: em uma instrução SQL, se você utilizar uma condição LIKE com o caractere curinga somente à direita (por exemplo, “where Campo like ‘Texto%'”), a busca não funcionará para os registros que têm espaços no início. Esse tipo de consulta considera o início do valor exato, portanto, para que a consulta retorne os dados, o usuário terá que digitar os espaços em branco no início, assim como fez ao gravar o registro. Ruim, não?

A segunda consequência é o alinhamento em Grids e relatórios. Se há espaços à esquerda em alguns registros, surgirá um efeito de desalinhamento, como se a tela ou o relatório estivesse com uma falha visual:

Exemplo de relatório desalinhado

A terceira consequência envolve a soma da quantidade de caracteres. Talvez o desenvolver queira calcular a quantidade de caracteres de um nome para inseri-lo adequadamente em um cupom fiscal ou aplicar regras de abreviação. Se houver espaços, a quantidade de caracteres será imprecisa.

Para resolver este problema, as linguagens de programação geralmente trazem uma função para retirar espaços em branco à esquerda e à direita de uma string, chamada Trim. Essa função pode ser utilizada antes de um registro ser gravado, de modo que os valores sejam persistidos no banco de dados já sem os espaços desnecessários. Porém, é importante destacar que o Trim não retira espaços em excesso dentro de uma string. Para isso, é necessário desenvolver uma função específica que percorra todas as letras de uma string removendo os espaços repetidos.

Número máximo de caracteres e intervalo numéricos

Dica básica, mas que muitas vezes passa por entre os dedos dos desenvolvedores. Quando você deixa de configurar o tamanho máximo em um campo e o usuário digita um valor maior do que o permitido, podem ocorrer duas situações: o valor é “cortado” e gravado pela metade no banco de dados, ou o usuário recebe uma exceção de estouro de campo. Erros dessa natureza são bastante comuns, já que o usuário não sabe o limite de caracteres que podem ser digitados em um campo.

A definição do número máximo de caracteres pode ser realizada através das propriedades dos próprios componentes. No Delphi e C#, a propriedade se chama MaxLength. No Java, uma das alternativas é utilizar um Document personalizado, sobrescrevendo o método insertString.

Para valores numéricos a situação pode ser um pouco diferente. Suponha que você tenha um campo que represente a porcentagem de desconto em uma venda e esqueceu de estabelecer o intervalo entre 0% e 100%. Por um golpe de distração, o usuário digita 250% e grava os dados. Mesmo que seja um valor aceitável pelo banco de dados, não faz sentido que exista um desconto de 250%. Por isso, quando a porcentagem envolve cálculos importantes, é fundamental ter uma restrição da faixa de valores.

Constantes

Algumas vezes fui questionado sobre a finalidade de se utilizar constantes no código-fonte. Em uma delas, o desenvolvedor disse que sempre usou variáveis, pois a única diferença é que as constantes não permitem que o seu conteúdo seja alterado, e este não era o seu caso. Sim, ele está correto. Mas a questão é que as constantes têm um motivo por não aceitarem a alteração de valores, isto é, serem read only (somente leitura).

Por exemplo, considere um software desenvolvido para uma fábrica de móveis. Em determinadas épocas do ano há uma variação do valor do IPI para estes produtos, no qual é utilizado em vários pontos do software, como pedidos, vendas, orçamentos, cálculo de preços e margens de lucro. Portanto, é extremamente importante que o valor do IPI seja sempre único em todos estes pontos do software. Constantes são úteis para casos como este. Basta concentrar o valor em um único local e utilizar a constante que o representa.

Além disso, utilizar constantes garante que o valor nunca será alterado. Ao utilizar variáveis, por outro lado, corre-se o risco do conteúdo ser modificado por uma rotina qualquer e afetar os cálculos no software.

Outra vantagem é a opção de criar uma classe exclusiva para guardar todas as suas constantes, facilitando a manutenção e compartilhando-as entre módulos. Em algumas empresas, os desenvolvedores criam constantes até para as mensagens de aviso e de confirmação que são exibidas na tela. Dessa forma, sempre haverá uma padronização das mensagens apresentadas ao usuário.

Só para efeito de conhecimento, é comum encontrar constantes declaradas todas em maiúsculas. Essa é uma convenção utilizada por muitos programadores, principalmente em linguagem Delphi.

Obrigado pela atenção, leitores. Abraço!

Leia também: Parte 1Parte 2Parte 3Parte 4Parte 5Parte 6Parte 7Parte 8, Parte 9Parte 11

Publicado originalmente no blog SubRotina

André Celestino

Mais artigos deste autor »

Desenvolvedor de software há 7 anos e autor do blog AndreCelestino.com. Graduado em Sistemas de Informação e pós-graduado em Engenharia e Arquitetura de Software com ênfase em Desenvolvimento Ágil. Atualmente trabalha como Engenheiro de Software.


Deixe seu comentário

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