ATIVIDADE REFATORACAO

Prévia do material em texto

CST em Análise e Desenvolvimento de Sistemas
Engenharia de Software – ESWD4
Antes de iniciarmos a refatoração, devemos certificar que não houve alteração no comportamento da aplicação, permanecendo a mesma funcionalidade anterior, com comportamentos corretos, evitando a duplicidade e aplicando a lógica e indentação adequada para o código.
No arquivo gilded_rose.py, possui este bloco com estas condições em if, portanto, vamos começar invertendo a condição dando “item.name != “Aged Brie”’ como resultado.
Assim, inverte-se o “Backstage passes”, pelo mesmo motivo da anterior, facilitando o entendimento de teste da condição caso ela seja positiva invés de negativa.
Com a condição elif, facilita a leitura ao invés de usar um if alinhado dentro de uma condição else, portanto, muda-se para elif.
	
Com a comparação de valores diferentes em grande quantidade, começa a se parecer com um “switch”, facilitando o entendimento, portanto, troca-se o aninhamento de “Sulfuras” e “item.quality > 0”.
Atualmente, ao inverter o “Sulfuras”, o teste torna-o para positivo, dando este resultado no código:
 
Novamente, aproxima-se a parecer com a instrução “switch”, no entanto, podemos dividir a condição de cima em duas, duplicando desta maneira:
 
Anteriormente, o código tornou-se mais longo, com duplicação, portanto, códigos redundantes podem ser excluídos, como por exemplo o teste adicional de “Backstage passes”, pois entendemos que é verdadeiro, portanto pode ser removido, no primeiro bloco, o “item-name == “Aged Brie”” está dentro da condição “Backstage passes” e poderá permanecer.
Atualmente, pode-se repetir o mesmo truque anteriormente com a condicional “Sulfuras”, desta vez será feito de uma vez com inclusão de merge em um elif
 
Agora é o momento de balancearmos, abaixo está o código inteiro, única mudança feita foi substituir decrementos e incrementos para “item.quality” e “item.sell_in”, para atribuições maiores.
Analisando toda a função, pode-se entender que nenhum update é feito quando “item.name == “Sulfuras,Hand of Ragnaros””, vamos extrair isso para uma cláusula de guarda.
Já pode-se ver que há update para o “item.sell_in” no meio desta função, portanto, ele está entre dois conjuntos de atualizações para o “Item.quality”, e será melhor variável por variável de cada vez, portanto move-se a atualização para o fim da função deste código, alterando a condicional “item.sell_in” conforme atualize.
Atualmente, possuímos ambas condições próximas da outra, parecidos estruturalmente, mas não são iguais, caso troque o aninhamento condicional no segundo, movendo o “item.sell_in < 1”, teremos o seguinte resultado: 
Pronto, os ifs parecem iguais e pode-se misturar
Desta maneira, está a aparecer com melhor compreensão, mas ainda pode ser melhorado. Na seção “Backstage_passes”, os ifs aninhados que averiguam “item.sell_in” só irão atualizar “item.quality” caso “item.quality < 50”, entretanto, podem ser levados para fora de sua condição
Finalizando, se reduz o aninhamento misturando as condições if, então, “item.quality” – “item.quality” é igual a 0.
Agora, o código está mais limpo e com melhor compreensão da principal função de seu funcionamento.
 
	Guarulhos 2022