Checklist Programação

Checklist de Programação

Para manter um código padronizado e conciso,
a Uniware preparou as tabelas a seguir, que
auxiliam a garantir uma escrita comum entre
os colaboradores e as medidas preventivas
antes de inserir alterações no software.
esse documento é uma cópia de:

D:\CVS\documentos\Check-list programação.xls

Padrões

Nomeclatura de tabelas	Segue o prefixo {:alnum:}{:alnum:}*_ (2 caracterres e 1 underline) afim de identificar qual projeto a tabela pertence. Exemplos: LB_ Tabelas do Unilab SA_ Tabelas do SAC FN_ Tabelas do Financeiro do Unilab HP_ Tabelas importadas do Hermes Pardini AL_ Tabelas importadas do Álvaro CR_ Tabelas importadas do Criesp SF_ Tabelas importadas do Sérgio Franco LOG_ Tabelas de logs de alterações em outras Tabelas U2U_ Interface Unilab
Nomeclatura de views	Utiliza o prefixo {:alnum:}{:alnum:}*V . Exemplos: Nome Aplicação Principal Tabela da view LBVPEDI Unilab LB_PEDI LBVEXAM Unilab LB_EXAM
Nomeclatura de campos	Como prefixo, é adicionado uma caracter para definir seu tipo. C Caracter N Numérico D Data e hora E Enumerado IMPORTANTE: Não criar campos do tipo booleano, pois esse tipo possui imcompatibilidade entre SGDB's. Utilizar um Enumerado de S/N quando for necessário.
Tipos de campo	Alguns tipos de campos adotam um padrão em qualquer parte do sistema, são eles: Monetário DECIMAL(12,2); Data, hora DATETIME; Booleano ENUM('S','N');
Tamanho máximo de uma tela MDI	1020x680
Nova Aplicação	Certificar-se de que: Todos os programadores possuem as ferramentas e compiladores necessários para dar manutenção. Criar uma pasta no subversion para a aplicação e a cada etapa efetivamente concluída, postar os fontes com uma descrição de acordo. Atualizar o artigo Aplicativos Uniware Quando a aplicação possuir uma versão de release, criar uma pasta no servidor com acesso para o suporte e disponibilizar os binários nela. Atualizar o artigo Aplicativos Uniware
Código fonte	Em Delphi, segue os seguintes padrões abaixo: Tipo Padrão Exemplo Constantes Caixa alta, espaçamento com "_" VALOR_PAGAMENTO_MINIMO Variáveis de Classe Iniciar com "F", capitalizado, sem espaçamento FCodiLab Variáveis do DB utilizar o mesmo nome do DB TUnilabNumeroAmostra.CCODIPOST Variáveis de function/procedure Iniciar com "v", capitalizado, sem espaçamento vVersao Variáveis globais Iniciar com "Global", capitalizado, sem espaçamento GlobalPostoColeta Parâmetros (function/procedure) Iniciar com "a", capitalizado, sem espaçamento aCodiExpr function/procedure aninhados Iniciar com "_", capitalizado _PedidoAlterado Classes (Tipos) Iniciar com "T", capitalizado, sem espaçamento TUnilabNumeroAmostra Units Iniciar com "U", capitalizado, sem espaçamento UUnilabNumeroAmostra Forms Iniciar com "F", capitalizado, sem espaçamento FExamesCad

Dependências

Criação de nova tabela	Verificar possíveis alterações em: ufExcluaDados ufExcluaDadosFinanceiro ufPreparaMov ufManutencao.RecalculaUlibseq ufManutencao.PreparaBaseCopiada uTransmissao ufPostCad (CTRANSTRAN) uTraduzirExcecao Dicionário de dados
Criação de chave Estrangeira	Afim de evitar erros nos bancos MySQL hospedados em Linux, deve-se criar separadamente a tabela, a chave e a chave estrangeira. Exemplo: CREATE TABLE LB_TESTE... ALTER TABLE LB_TESTE ADD KEY FK_TESTE_CODI (CCODITESTE) ALTER TABLE LB_TESTE ADD CONSTRAINT FK_TESTE_CODI FOREIGN KEY (CCODITESTE) REFERENCES LB_OUTRO (CCODIOUTRO)
Criar Campo na LB_EXAM	*Na tabela ULIBMETA criar um registro com o nome e definição do campo. (TFExamRelHistAlter depende desta tabela pra funcionar) Verificar se para amostra adicional é necessário copiar o valor do campo do pai para os filhos: CADAntesCommit e CCODIPAIEXAMValidar Ao Criar novos campos na LB_EXAM deve verificar as rotinas UFExamExporta e UFExamImporta para ver se o campo criado pode influenciar na rotina.
Criar campo no configurador na CFEX	Incluir carga do conteúdo do campo nos relatórios de lista de exames - UFResuRelLista, UFResuRelListaPaci
Alterar/Criar relatório de fatura	Refletir alterações na exportação da fatura p/ excel
Criar nova Unit	Verificar se precisa incluir também nos projetos: Unilabw, Unilab_BETA, Unilaudos e unilabSRV Remover do delphi o autocreate que ele gera automaticamente para o form
Incluir Campo no TISS	Incluir em todas as versões; Na impressão parcial/full; no configurador da guia full
Gravar datahora da coleta	Rotinas que gravam coleta: PediCad; UfColeta; UFDesfazColeta; UFRecoleta; UUnilabExpr; PediImp (imprime mapa de não coletado ele põe a data de coleta auto); TercLabCad (qdo inclui no lote um não coletado coleta auto);
Gravar datahora da triagem	Rotinas que gravam triagem: UFPedicad UAuxGlobal UFColeta UFTriagem UFRecoleta UnilabExpr
Incluída tabela na transmissão	Constante: Versao_do_sistema_de_querypack - Incrementar quando tiver alteração nas funções queryPack e QueryUnPack Constante: Versao_do_sistema_de_transmissao – Incrementar quando incluir/excluir uma tabela ou informação a ser transmitida Versão do executável: em Project > Options > Version Info: Incrementar em qualquer nova versão Versão do Unilab: A versão do Unilab (componente Sys da UFMain) não é considerada pelo programa de transmissão. Mas a versão do Unilab que está no banco é enviada junto no pacote e verificada nas pontas para ver se bate; Mas não precisa recompilar o servidor de transmissão só porque mudou a versão do Unilab.
Update na expr	Sempre que fizer um update na expr incrementar a ulibrela
Campo chave tipo varchar	Sempre ativar a propriedade UsaTrim do TUEdit Quando puder informar o valor do campo na mão
Alertas	Sempre que fizer alguma modificação nos alertas dos exames: Eles podem ser informados no cadastro de exame e cadastro de tabela de preços (UFExamValo e UFTabeCad). Eles são exibidos no cadastro de pedidos e no orçamento.
Alterações na Estrutura do Banco de dados	Atualizar o dicionário de dados: D:\CVS\light\documentacao\Dicionário de Dados Unilab (v.2.0.2).mwb
Revisão Final 1 - Hints e Warnings	Conferir os Hints e warnings gerados pelo Delphi e eliminá-los corrigindo os possíveis erros que eles podem estar indicando.
Revisão Final 2 - Dependências	olhar no diff cada função que foi alterada, e conferir no Pascal Browser se a mexida gera efeito colateral nas dependências.
Revisão Final 3 - Teste de breakpoint	Olhar no diff e colocar um breakpoint em cada bloco alterado e rodar o programa debugando e conferindo o resultado da execução, se o programa fez o que era esperado. Cada breakpoint que ele passar e fizer o que é esperado, tirar o breakpoint até que todos os breakpoints sejam removidos. O objetivo é testar todas as possibilidades englobadas pela alteração. Caso a implementação seja grande demais tornando esta etapa do checklist muito demorada, vamos conversar com o Cláudio e decidir se queremos dedicar tanto tempo conferindo aquela alteração.