Mudanças entre as edições de "Checklist Programação"
(→Padrões) |
|||
Linha 129: | Linha 129: | ||
|- | |- | ||
|Comentários || Como padrão de escrita segue o modelo com a forma de comentários do código: | |Comentários || Como padrão de escrita segue o modelo com a forma de comentários do código: | ||
− | + | ||
− | + | ''{Descrição da Unit}'' | |
− | + | unit MyUnit; | |
− | + | interface | |
− | + | ||
− | + | const | |
− | + | ''{Descrição da Constante}'' | |
− | + | MyConstant = 4; | |
− | + | ||
− | + | type | |
− | + | ''{Descrição da Classe}'' | |
− | + | TMyClass = class | |
− | + | public | |
− | + | ''{Descrição da Variavel}'' | |
− | + | MyField: Integer; | |
− | + | ''{Descrição do Método}'' | |
− | + | procedure MyMethod; | |
− | + | end; | |
− | + | ||
− | + | ''{Descrição da Procedure}'' | |
− | + | procedure MyProcedure; | |
+ | |||
+ | implementation | ||
+ | |||
+ | procedure MyProcedure; | ||
+ | begin | ||
+ | |||
+ | { comentário do código } | ||
+ | if MyField = 0 then begin | ||
+ | |||
+ | { documentar aqui o propósito do SQL abaixo, e o que é | ||
+ | cada campo documentar usando comentário de linha como segue } | ||
+ | SQL := 'CREATE TABLE X ( '+ // DESCRIÇÃO DA TABELA X | ||
+ | ' CAMPO1 VARCHAR(171) '+ // DESCRIÇÃO DO CAMPO 1 | ||
+ | ' CAMPO2 INTEGER) '; // DESCRIÇÃO DO CAMPO 2 | ||
+ | end; | ||
+ | |||
+ | end; | ||
+ | |||
+ | end. | ||
|} | |} | ||
Edição das 15h29min de 20 de agosto de 2013
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:
| ||||||||||||||||||||||||||||||||||||
Nomeclatura de views | Utiliza o prefixo {:alnum:}{:alnum:}*V . Exemplos:
| ||||||||||||||||||||||||||||||||||||
Nomeclatura de campos | Como prefixo, é adicionado uma caracter para definir seu tipo.
IMPORTANTE: Não criar campos do tipo booleano, pois | ||||||||||||||||||||||||||||||||||||
Tipos de campo | Alguns tipos de campos adotam um padrão em qualquer parte do sistema, são eles:
| ||||||||||||||||||||||||||||||||||||
Tamanho máximo de uma tela MDI | 1020x680 | ||||||||||||||||||||||||||||||||||||
Nova Aplicação | Certificar-se de que:
| ||||||||||||||||||||||||||||||||||||
Código fonte | Em Delphi, segue os seguintes padrões abaixo:
| ||||||||||||||||||||||||||||||||||||
Tabulação | Padronizar em 2 espaços a tabulação. | ||||||||||||||||||||||||||||||||||||
Cores |
| ||||||||||||||||||||||||||||||||||||
Comentários | Como padrão de escrita segue o modelo com a forma de comentários do código:
{Descrição da Unit} unit MyUnit; interface const {Descrição da Constante} MyConstant = 4; type {Descrição da Classe} TMyClass = class public {Descrição da Variavel} MyField: Integer; {Descrição do Método} procedure MyMethod; end; {Descrição da Procedure} procedure MyProcedure; implementation procedure MyProcedure; begin { comentário do código } if MyField = 0 then begin { documentar aqui o propósito do SQL abaixo, e o que é cada campo documentar usando comentário de linha como segue } SQL := 'CREATE TABLE X ( '+ // DESCRIÇÃO DA TABELA X ' CAMPO1 VARCHAR(171) '+ // DESCRIÇÃO DO CAMPO 1 ' CAMPO2 INTEGER) '; // DESCRIÇÃO DO CAMPO 2 end; end; end. |
Dependências/Impacto
Quando usar uma das funções ao lado usar na ordem |
|
Permitiu ao posto de coleta alterar campo da expr. | Na transmissão da expr do posto para a central tem que colocar um tratamento específico senão a informação não será transmitida. |
Novo campo na LBVPEDI | Criar o campo também na LBVPEDI_NAO_COLETADOS |
Criação de nova tabela | Verificar possíveis alterações em:
|
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) Caso a chave estrangeira for relacionada com a tabela de exames, verificar TFExamRename.Processar. |
Criar Campo na LB_EXAM | Ao adicionar um novo campo na tabela:
|
Criar campo no configurador na CFEX | Incluir carga do conteúdo do campo nos relatórios de lista de exames - UFResuRelLista, UFResuRelListaPaci
Para qualquer novo campo do configurador, incluir UCfgTab.TTabTipo. E tratar erro na carga do conteúdo das variáveis. |
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 |
|
Gravar datahora da coleta | Rotinas que gravam coleta:
|
Gravar datahora da triagem | Rotinas que gravam triagem:
|
Incluída tabela na transmissão | Constante: Versao_do_sistema_de_querypack - Incrementar quando tiver alteração nas funções queryPack e QueryUnPack
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 do componente Sys da UFMain não é considerada pelo programa de transmissão. Mas a versão do executável é. Precisa recompilar o servidor de transmissão sempre que mudar a versão do Unilab. |
Update na expr | Sempre que fizer um update na expr incrementar a ulibrela |
Novo Interfaceamento com Apoio/Equipamento |
|
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:
|
Novo campo etiqueta |
|
Atualização com interação do usuário |
Quando for executar uma rotina na UFAtualiza que precisa de alguma informação de usuário, chamar o procedimento na função TFAtualiza.Atualiza: assim a pergunta cai só no final da atualização. Assim agente pode 'deixar rodando' a atualização |
Executar o UNILAB CONSULTA |
Project -> Options -> directories/Conditionals -> Conditionals: incluir: xxxxxxxx " ;Ver_Print_Only " |
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. |
Documentação do Ticket (UniSuite) | Não esquecer de colocar no Ticket a Analise, Notas de Teste e Notas da Versão (Copiar do Pivotal). |