O tempo passa as regras de sistemas mudam! e os famosos ajustes vão sendo feitos diariamente nas regras LSP, sejam em relatórios, Portal RH, Processos, etc. Sempre nestas alterações o tempo para ajustes é escasso, devido aos prazos curtos necessários para sua alteração ou manutenção, e geralmente o código gerado não fica na melhor estrutura possível após as primeiras manutenções, ainda mais quando não é a mesma pessoa que faz as alterações, isso ajuda a gerar diversos pontos na regra de lógicas duplicadas! as técnicas de refactoring propoem solucionar estas situações.
Para o refactoring a frase "em time que está ganhando não se mexe" não é valida , deve ser alterado sim!Segundo a wikipedia: Refatoração (do inglês Refactoring) é o processo de modificar um sistema de software para melhorar a estrutura interna do código sem alterar seu comportamento externo.
Segundo Martin Fowler a refatoração é uma técnica disciplinada para reestruturar um corpo de código existente, alterando a sua estrutura interna sem alterar o seu comportamento externo. O coração da técnica é uma série de pequenas transformações preservando o comportamento. Cada transformação (chamada de refactoring) faz um pouco, mas uma série de transformações podem produzir um resultado significante para a qualidade do sistema. Já que cada refatoração é pequena, é menos provável que ela cause algum problema. O sistema é mantido 100% funcional depois de cada refactoring. Reduzindo as chances de algum problema grave no sistema no final da reestruturação.
Algumas situações comuns são encontrados em regras LSP com mais de 2 novas implementações ao longo de sua existência:
- Variáveis em duplicidade com a mesma funcionalidade (duplicated code) ;
- Declaração de variáveis e cursores em duplicidade (duplicated code) ;
- Código mal estruturado (long method);
- Duplicidade de lógicas condicionais (duplicated code);
- Número excessivo de linhas de código e espaçamento entre linhas (Bad Indentation) ;
- Códigos comentados que não são mais utilizados;
- Comentário mal feitos ou incompletos;
Quando chegamos a esta situação, utilizar-se do conceito de refactoriong de código pode ser uma redução no tempo de manutenção desta regra na proxima alteração.
Refactoting no seu conceito nada mais e do que refatorar o código, reestruturar , deixa-lo de uma maneira mais organizada como um todo. basicamente o código fica mais organizado e legível sem alterar no propósito e resultado da regra.
Neste artigo pretendo descrever um pouco como aplicar o conceito de Refactoring em LSP, para isso vamos adotar alguns padrões de códificação.
1. Refactoring de Linhas desnecessárias
Retire espaços desnecessários entre as regras , crie as regras organizadas por blocos como abaixo:
A.Bloco de Definição (Variáveis, Cursores,Funções)
A.1 Bloco de cursores;
A.2 Bloco de Variáveis Numericas
A.3 Bloco de variáveis
B. Bloco Lógico da Regra, sempre separado por assunto.
2. Refactoring de Cursores;
Um exemplo de um Cursor com linhas desnecessárias :
Cur_R006Esc.SQL "SELECT HorMes \
FROM R006ESC \
WHERE CodEsc = :xCodEsc ";
Cur_R006Esc.AbrirCursor();
Se (Cur_R006Esc.Achou)
Inicio;
xValSal = xValSal * (Cur_R006Esc.HorMes / 60);
Fim;
Cur_R006Esc.FecharCursor();
Um exemplo melhor organizado , mais direto de Cursor com 6 linhas a menos
Cur_R006Esc.SQL "SELECT HorMes \
FROM R006ESC \
WHERE CodEsc = :xCodEsc ";
Cur_R006Esc.AbrirCursor();
Se (Cur_R006Esc.Achou)
xValSal = xValSal * (Cur_R006Esc.HorMes / 60);
Cur_R006Esc.FecharCursor();
Outro Exemplo só com o cursor parcial ( ANTES )
C038HSA.SQL "SELECT ValSal, \
TipSal \
FROM R038HSA \
WHERE NumEmp = :vNumEmp \
AND TipCol = :vTclSbs \
AND NumCad = :vCadSbs \
ORDER BY DatAlt DESC ";
Depois com os campos de resultado do SQL na mesma linha, claro considere um limite de 10 campos para salto de linha
C038HSA.SQL "SELECT ValSal, TipSal \
FROM R038HSA \
WHERE NumEmp = :vNumEmp \
AND TipCol = :vTclSbs \
AND NumCad = :vCadSbs \
ORDER BY DatAlt DESC ";
3. Refactoring de Comentários.
comentário desnecessário não devem ser mantidos , por exemplo muitas veses colocamos comentário referentes a situações especificas que estamos testando, porteriormentes os valores serão outros não polua sua regra com comentários que não tragam informação consistente.,
Exemplo de comentário adicionado abaixo de um cursor com testes realizados na epoca,
que contribuiu para testes na epoca e não trazem nenhuma informação no decorrer
do tempo e poulem o código
/* --- Teste da rotina de lancamentos ---
and datini <= '2002-03-01' and (datfim >= '2002-03-01' and datfim <= '2002-03-30')
or datini <= '2002-03-01' and (datfim >= '2002-03-01' and datfim >= '2002-03-30')
or datfim <= '2002-04-28' and (datini >= '2002-03-01' and datini <= '2002-03-30')
or datfim >= '2002-04-28' and (datini >= '2002-03-01' and datini <= '2002-03-30')
*/
4. Refactoring em Condicionais
Código ANTES
Se ((CodEvt <> 200) e (CodEvt <> 213))
{
vRefEvt = RefEvt;
}
DEPOIS ( 2 linhas a menos )
Se ((CodEvt <> 200) e (CodEvt <> 213))
vRefEvt = RefEvt;
5. Refactoring de regras descenessárias ou não mais utilizadas.
Na Pasta LSP Podem existir regras que não estejam mais utilizadas, neste caso se quer mantelas por algum motivo, crie uma pasta em senior/vetorh chamada lsp-deprecate , onde vamos adicionar as regras não utilizadas mais, crie dentro deste pasra um arquivo com o nome LEIAME.txt para orientar a função deste diretório na pasta do sistema Senior.
Conteúdo do arquivo LEIAME.TXT
Neste diretorio são arquivadas regras do sistema Senior
que não são mais utilizadas e vinculadas a processos
Data: <DD/MM/YYYY>
Autor: <Nome do Consultor Senior>
Este artigo apresentou algumas tecnicas de refactoring aplicadas a LSP e estará em constante evolução, acompanhe nosso portal e mantenha-se atualizado, comente, contribua, se você fez alguma técnica que simplifica o código LSP nos encaminha e publicaremos.
Estas técnicas foram aplicadas em uma base com mais de 10.000 linhas de código LSP e gerou uma redução de 10% de código, sendo assim 10% a menos itens a serem mantidos e passíveis de manutenção.
