Consultor Senior - O seu consultor On-Line

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.  

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.