7.1 - Boas práticas

7.1 - Boas práticas

Boas práticas é um conjunto de técnicas utilizadas para resolver um determinado problema. No nosso caso, é uma forma de melhorarmos a qualidade da nossa aplicação, já no início da mesma, com a construção de uma base sólida e bem formada, ou ao término da aplicação, aumentando a segurança dos dados, por exemplo. Abaixo veremos as principais boas práticas identificadas.

a. Não reinventar a roda

Vira e mexe na informática nos defrontamos com problemas que parecem intransponíveis, sem nenhuma solução imediata em nossas cabeças. Só que muitas vezes, esquecemos que outras pessoas podem e devem ter passado por problemas parecidos, se não iguais aos nossos. Por isso, caso você tenha um problema assim, verifique sempre a Comunidade Apex do TCU, acessando a Biblioteca Digital, o fórum ou os links úteis lá presentes.


Como vimos no item 6.3, nossas aplicações nascem no ambiente de desenvolvimento, sofrem testes, ajustes, até atingirem o ponto de maturação ideal para serem migradas para produção. Uma vez na produção elas só devem sofrer ajustes finos, mas no caso de ajustes mais complexos, correções, alterações ou inclusões de regras de negócio, devemos voltar ao ambiente de desenvolvimento para lá fazer isso.

Após esta nova etapa, os testes e ajustem são feitos novamente até chegarmos ao ponto de nova migração para a produção. Antes de migrarmos, devemos exportar a aplicação (assista ao vídeo) e manter o arquivo da exportação em algum lugar seguro, para que ele possa nos servir de backup, caso algum problema surja com a versão nova.

c. Seguir algum padrão de nomenclatura

Quando estamos construindo uma base de dados, pode nos faltar criatividade para criarmos objetos (como tabelas, funções etc) com um nome que realmente represente a funcionalidade do objeto.

Vale a pena ressaltar que esforço extra nesta hora é imprescindível, uma vez que, depois de criado, a tendência é o objeto se tornar referenciável e referenciado pelos mais diversos códigos. Imagine se a tabela ALUNO se chamasse TAB1. Em um primeiro momento o desenvolvedor que a criou poderia até saber sua real função, mas no caso de outro desenvolvedor vir apoiá-lo ou até mesmo o próprio criador da tabela após certo tempo de afastamento do projeto, pode esquecer o que ela faz. Então concluímos que um objeto com um nome significativo facilita o desenvolvimento e reduz os custos da manutenção.

Além de termos esta necessidade de um nome significativo, também temos um conjunto de prefixos e sufixos que ajudam a tornar mais claro o tipo do objeto, além de padronizá-los. Veja esta relação:


d. Pensar em segurança desde o início

Segurança é sempre o ponto mais sensível de uma aplicação. Sem ela, qualquer um poderia ter acesso a dados, a aplicações restritas, o que pode gerar uma série de problemas das mais diversas ordens. Veremos agora algumas dicas de segurança:

a) Nunca deixar uma aplicação pública. A única exceção é a versão de produção de uma aplicação declaradamente pública, acessível por qualquer pessoa na internet, seja diretamente, seja via sites de pesquisa (Google, etc).

b) Evitar deixar uma aplicação em desenvolvimento acessível a qualquer pessoa do TCU (inclusive terceirizados e estagiários) ao autenticar via SSO. A versão em desenvolvimento deve ficar com a autenticação padrão do Apex e sem apelido.

c) Sempre utilize Exibir como Texto (caracteres especiais de escape). Essa técnica é utilizada para garantir que, caso o usuário preencha o valor de um campo com um código HTML, o Apex interprete o código fornecido pelo usuário, que pode ser danoso à aplicação e mostre como se fosse um valor texto normal. Observe nas imagens abaixo o que acontece quando não nos precavemos.

c.1 – Temos abaixo um relatório cujo campo Nome está como Escolher Coluna de Relatório Padrão.


c.2 – Agora temos o usuário preenchendo com um código Javascript no nome do aluno. Este código exibe a mensagem “Hello World” na tela. É inofensivo, mas poderia ser um script potencialmente perigoso para a aplicação ou para o próprio computador do usuário.


c.3 – Ao entramos na tela deste relatório, observe o que acontece.


E após clicarmos no OK, vemos no relatório que o nome do aluno ficou em branco.


c.4 – Para se evitar isso, altere no relatório o tipo da coluna para Exibir como Texto (caracteres especiais de escape).


c.5 – Retornando ao relatório veremos que o script não foi processado pelo Apex, e sim entendido como um texto qualquer.


Agora é com você!

Verifique se as páginas de sua aplicação atendem as questões mínimas de segurança apresentadas. Se não estiverem ok, as ajuste.

e. Criar trilha de auditoria

Também é boa prática armazenar uma trilha de auditoria de fácil consulta, especialmente em um órgão de controle como o TCU. A implementação mais básica nos permite saber quando foi efetuada a última modificação na tabela e por quem.

Passos para criar a trilha de modo rápido:

1- Acrescente nas tabelas a serem auditadas os campos


2- O formulário que edita dados da coluna a ser auditada deve ter os itens PX_INSERIDO_POR e PX_DATA_ENTRADA ocultos ou mostrados como texto. X é o número da página.

3- Edite e configure o item PX_INSERIDO_POR como mostrado abaixo:


4- Edite e configure o item PX_DATA_ENTRADA como mostrado abaixo (atenção para o tipo de valor default):


Agora é com você!

Crie trilhas de auditoria para o sistema MinhaEscola:

1-Acrescente regra de negócio no DGA indicando quais tabelas são minimamente auditáveis. Sugestão: pelo menos nas tabelas que interferem em questões financeiras!
2-Altere o modelo de dados acrescentando os campos INSERIDO_POR e DATA_ENTRADA, implemente as trilhas de auditoria e atualize o DGA com os novos campos.


Como vimos no item 5.2 deste curso, o uso de packages trazem certas vantagens para o nosso desenvolvimento. A título de revisão, as veremos novamente agora.

Modularidade e Facilidade de Manutenção: através do encapsulamento das estruturas relacionadas num módulo nomeado. Cada package fica fácil de entender e a interface entre packages é simples, clara e bem definida.

Melhor performance: na primeira chamada de um subprograma dentro de uma package, toda a package é carregada na memória. Após isto, todas as chamadas aos subprogramas de uma package não vão precisar de I/O de disco. Apenas uma cópia da package em memória é necessária para todos os usuários.

Design de aplicação fácil: a codificação e a compilação da especificação e do corpo da package podem ser feitas separadamente.

Funcionalidades Adicionadas: as variáveis públicas e os cursores persistem durante a sessão. Assim, eles podem ser compartilhados por todos os subprogramas que são executados neste ambiente. As variáveis públicas e os cursores também permitem o reaproveitamento de dados entre as transações sem a necessidade de armazenamento no banco de dados.

Outra boa prática, aí não se tratando apenas de package e sim de todo o código gerado, são os comentários no código. Eles ajudam a tornar uma rotina menos complexa, pois o desenvolvedor que a gerou pode descrevê-la com suas próprias palavras, deixando claro para qualquer um que vier a dar manutenção neste código qual era a sua intenção. Para comentar uma linha apenas utilize “--" antes da linha, mas se for necessário comentar um bloco de código utilize “/*” no início do bloco e “*/” no final do mesmo.

Sempre que possível, comente seu código!

g. Usar bind variables :Pn_ITEM

Sempre usar bind variables em SQL (ex.: :Pn_ITEM).

Com isso tem-se um SQL dinâmico, evitando-se assim o uso de valores fixos nas consultas, o que demanda manutenção no código, caso eventualmente ele mude.
Um benefício adicional é o aumento da segurança do código em relação a outras soluções.

SELECT qtde_vagas
FROM turma
WHERE cod = :p14_cod_turma;


h. Evitar views materializadas


Evite views materializadas, a não ser quando estritamente necessário. Elas devem ser evitadas porque a migração desse tipo de objeto é mais complexa. Além disso, se mal utilizadas, custam caro para manter réplicas de dados que nem sempre levam ao aumento de desempenho. Na dúvida, acione o suporte da Setec.

i. Evitar campos LOB

O Apex permite trabalhar com campos do tipo CLOB e BLOB. LOB vem de Large OBjects, e é um tipo de dados que pode armazenar grandes quantidades de informação.
Por sua natureza, não é possível agrupar dados a partir de campos LOB via SQL.

a) Use o CLOB em vez de VARCHAR2 apenas quando se tiver certeza que 4000 caracteres de texto não serão suficientes. A concatenação de CLOBs, a partir de 32KB, fica mais complexa, exigindo uso da API DBMS_LOB da Oracle.

b) O principal uso de BLOBs é o armazenamento no banco Oracle de imagens, documentos, áudio e vídeo. O problema é que esses arquivos consomem muito espaço físico de banco. Como o custo do armazenamento, manutenção e backup do banco Oracle é muito caro, não se deve utilizar o campo BLOB no TCU.

E se você precisar fazer links a arquivos e imagens?

Uma alternativa é inserir os arquivos no Portal TCU, servidor de arquivos ou Sisdoc, seguindo as regras institucionais existentes, e fazer links normais a esses arquivos.
Um exemplo prático pode ser visto em tutorial disponível na Biblioteca Digital da Comunidade Apex (após Login Inteligente).Vamos deixar você encontrar esse arquivo!
Agora é com você!

Para mais dicas de boas práticas no desenvolvimento com Apex, visite os links:

http://www.oracle.com/technology/pub/articles/wootton-apex-bps.html
http://www.oracle.com/technology/products/database/application_express/pdf/apex_best_practices.pdf
http://www.oracle.com/technology/products/database/application_express/html/competition.html (itens 2.2, 2.4, 2.5 e 3 todo)