Profissionais TI - Pra quem respira informação

A intenção inicial era elaborar somente quatro artigos sobre este assunto (Parte 1, Parte 2, Parte 3, Parte 4). No entanto, recebi algumas sugestões para continuar escrevendo mais algumas dicas referentes ao desenvolvimento de um bom software. Novamente agradeço aos leitores que acompanharam e divulgaram os quatro primeiro artigos, e espero que essa quinta parte também seja interessante para vocês.

Liberação de objetos da memória

Quando um aplicativo é iniciado, o sistema operacional se encarrega de alocar o espaço necessário na memória para a sua execução. Esse espaço é variável, e depende da quantidade de recursos que o aplicativo possui. Ao abrir uma tela do aplicativo, todos os campos de edição, botões e rótulos (labels) são criados na memória em runtime (tempo de execução), e permanecem nela até que sejam liberados. O problema surge quando o desenvolvedor esquece ou deixa de liberar esses objetos, acumulando recursos desnecessários na memória do computador. Por exemplo, supõe-se que instanciamos um objeto chamado “objCliente” da classe Cliente na inicialização de um formulário. Ao terminar de manipulá-lo, é necessário desalocá-lo da memória, já que ele não estará mais em uso. Caso não o fizer, o objeto permanecerá alocado na memória, muitas vezes sem o consenso do desenvolvedor. Dessa forma, na próxima vez que o formulário for inicializado, uma nova instância do objeto será criada em outro endereço de memória. Então imagine: ao abrir o formulário 10 vezes, teríamos 10 objetos “objCliente” criados, ao passo de que somente um seria necessário. É por isso que alguns usuários reclamam que o aplicativo começa a ficar lento após um tempo de uso.

Cada linguagem de programação tem uma forma distinta de liberar objetos da memória. No Delphi, basta utilizar o comando FreeAndNil para essa finalidade.

Criação de componentes

Se o seu objetivo é reduzir código e padronizar a aplicação, criar componentes é uma ótima prática. Suponha que em determinado projeto decidimos modificar os campos de texto da seguinte forma:

• ao receber o foco, ele mudar de cor
• o campo não pode possuir conteúdo em branco
• ao sair do campo, se o valor for uma data, a aplicação deve validá-la

Para que essas funcionalidades tenham efeito, é necessário codificar cada campo de texto em toda a aplicação, não é? Oras, por quê não criar um componente com essas características? Dessa forma, utilizaríamos esse componente ao invés do campo de texto nativo da ferramenta e não precisaríamos codificar cada um deles, já que as funcionalidades estariam implícitas no componente criado. Além disso, se futuramente for necessário modificar ou adicionar uma característica (por exemplo, trocar a fonte de texto), basta modificar o componente e a alteração será refletida em todos as instâncias do componente inseridas na aplicação.

Quando o desenvolvedor cria vários componentes personalizados, pode-ser dizer que ele está definindo um Framework de desenvolvimento.

Triggers e Stored Procedures

Implementar algumas regras de negócio no banco de dados pode trazer grandes vantagens para a aplicação, tanto no sentido de automação de operações como no desempenho. Na verdade, Triggers e Stored Procedures nunca deixaram de ser recursos essenciais no desenvolvimento de um software. Vou citar apenas uma das vantagens: em uma aplicação Cliente/Servidor ou Multicamadas, criar Triggers e Stored Procedures no banco de dados evita que várias chamadas sejam feitas ao servidor. Imagine que, ao excluir um pedido, seja necessário também excluir os itens do pedido (no sentido mestre/detalhe). Pela aplicação, faríamos duas solicitações ao banco de dados: uma para excluir os itens e outra pra excluir o pedido em questão, certo? Pois bem, se centralizarmos essa operação em uma Trigger no banco de dados, apenas uma solicitação será feita, ou seja, a Trigger se encarregará de excluir os itens antes de excluir o pedido, tornando-se um processo automatizado. Para aplicações de pequeno porte pode não surtir tanta diferença, mas em uma aplicação com vários usuários conectados simultaneamente a vantagem é notável, inclusive pelo motivo de redução no tráfego na rede.

Busca por fonema

Essa dica é bem interessante, embora a implementação dessa funcionalidade seja complexa. Antes de continuar, vale lembrar que um fonema, a grosso modo, é a unidade de som produzida ao pronunciar uma determinada letra. Por exemplo, na língua portuguesa, as letras “i” e “y” possuem o mesmo som (mesmo fonema), e isso causa alguns problemas na busca de dados em um aplicativo. Sabe por quê?

Imagine que o sistema tenha vários clientes cadastrados, e três deles tenham o nome de Érica, Erica e Érika, respectivamente. Ao atender a ligação de uma dessas clientes, o usuário solicita o nome, ouve, e digita “Erica” (sem acento) no campo de dados para localizar o registro. Obviamente, apenas um dos nomes aparecerá na tela. Porém, a cliente que ligou é a Érika (com acento e com “k”)! Já que o resultado não apareceu na busca, o usuário irá informar que ela não está cadastrada no sistema. Bom, aí você já viu, rsrs.

Busca por fonema consiste em agrupar letras que tenham o mesmo som em uma mesma consulta. No exemplo acima, ao digitar “Erica”, os três registos seriam exibidos na tela, já que o acento e os fonemas de “c” e “k”, neste caso, produzem o mesmo som.

Obrigado pela visita e pela atenção!
Um abraço!

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

Publicado originalmente no blog SubRotina