Menu

Refatoração de código: o que você precisa saber sobre isso

code refactoring what you need know about it

Experimente Nosso Instrumento Para Eliminar Problemas

Noções básicas sobre refatoração de código: a perspectiva de um testador

O termo 'Refatoração' é usado principalmente para indicar limpeza / redesenho de código necessário.

Neste tutorial, entenderemos a definição de refatoração, discutiremos a necessidade de refatoração de código e revisaremos o impacto do código de refatoração em vários membros da equipe do projeto. Também discutiremos a resposta para a pergunta mais importante - Como testador, por que você precisa saber sobre refatoração?

Além disso, também discutiremos alguns estudos de caso para esclarecer o conceito.

Refatoração de código

O que você aprenderá:

Introdução à Refatoração

Para começar, vamos primeiro entender o que realmente é refatoração.

Refatorar é essencialmente uma prática ou processo de melhorar o código e / ou banco de dados, mantendo a funcionalidade existente. A ideia é transformar o código ineficiente e excessivamente complicado em um código mais eficiente, de preferência mais simples e fácil.

A refatoração de código também ganhou impulso com mais equipes agora, seguindo a abordagem de Desenvolvimento Ágil de Software. As equipes de projeto geralmente têm tempo limitado para implementar ou estender a funcionalidade dos recursos existentes e do código que está limpo. O código, que é fácil de entender e manter, certamente contribui muito para cumprir o prazo de iteração.

Necessidade de Refatoração de Código

Se estivermos mantendo a funcionalidade original do aplicativo ou módulo, surge a pergunta: Por que nos incomodamos em refatorar? Bem, existem vários motivos pelos quais um módulo ou parte do código em particular pode precisar ser refatorado, como:

  1. Cheiros de código
  2. Dívida técnica
  3. Abordagem de desenvolvimento ágil de software, etc.

Discutiremos esses pontos em detalhes nas seções a seguir.

# 1) Cheiro de código:

Todos nós podemos entender que, quando a comida começa a cheirar, isso indica que provavelmente está estragando - isso também é verdadeiro para o código! O cheiro do código é uma indicação de que um problema muito sério pode existir no código.

A seguir estão alguns odores comuns de código:

  • Presença de código redundante ou idêntico.
  • Uma variável declarada que não é usada em nenhum lugar no resto do código.
  • Projeto de código muito complicado.
  • Classe de código que faz muito pouco e não justifica a existência da classe definida. Essas classes são conhecidas como classe preguiçosa ou freeloader.
  • A existência de muitas condições e loops com potencial para serem decompostos e simplificados.
  • O código é construído de forma que uma mudança em uma parte do código exija que a mudança seja implementada em outros lugares também.

Os cheiros do código tornam-se mais aparentes com o passar do tempo. Conforme o aplicativo ou sistema cresce, eventualmente esses odores de código começam a afetar o desenvolvimento do código, a manutenção e até mesmo o desempenho do sistema em cenários extremos.

# 2) Dívida técnica:

Durante o desenvolvimento de um software, durante o tempo e os recursos limitados disponíveis, muitas vezes podemos tomar atalhos para alcançar os resultados desejados.

Considere um recurso que precisa ser adicionado a um módulo existente. Após a discussão, a equipe restringe 2 abordagens para adicionar esse recurso. A abordagem A, que leva 2 sprints para ser entregue, será a abordagem aprovada de longo prazo. A Abordagem B leva apenas 5 dias para ser entregue, é um hack codificado e desordenado que é projetado apenas para atender o módulo em curto prazo.

Se a equipe estiver sob pressão para entregar o recurso dentro de um tempo limitado, eles podem concordar em seguir a Abordagem B por enquanto e adicionar a Abordagem A no backlog para o futuro. Com isso, essa equipe acabou criando para si a dívida técnica.

Em termos simples, a dívida técnica no desenvolvimento de software refere-se ao retrabalho adicional ou sobrecarga necessária para colocar as correções adequadas no lugar ou fazer as coisas da 'maneira certa'.

Os sistemas legados tendem a adquirir enormes dívidas técnicas ao longo do tempo, o que, por sua vez, pode tornar o aplicativo suscetível a falhas e difícil de suportar e manter.

Consulte Mais informação=> O que é departamento técnico

# 3) Seguindo a abordagem de desenvolvimento ágil de software:

A abordagem de desenvolvimento ágil de software defende o desenvolvimento incremental. Sem um código limpo, bem estruturado e fácil de manter, não seria possível para as equipes estender o código existente a cada iteração. Se o código for alterado sem a refatoração adequada, isso pode contribuir para o odor do código ou problemas técnicos.

Esta relação é descrita no diagrama abaixo

Abordagem de desenvolvimento ágil de software

Leitura recomendada => Principais ferramentas de análise de código

Por que um controle de qualidade precisa saber sobre refatoração?

Tudo o que discutimos até agora neste tutorial parece estar relacionado à codificação e parece o tipo de coisa com que um desenvolvedor deve se preocupar.

Então, por que estamos discutindo esse conceito não relacionado na Comunidade de Ajuda do Teste de Software? Continue lendo o restante deste tutorial para obter a resposta a esta pergunta.

# 1) Para testadores / desenvolvedores de unidade

Durante a refatoração do código, conforme o novo código é inserido, as classes antigas são atualizadas, as novas classes são adicionadas e os testes de Unidade existentes podem falhar agora. Além disso, para sistemas legados, pode não haver nenhum teste de unidade implementado. Esses novos testes de unidade precisarão ser criados e configurados do zero na maioria dos casos.

# 2) Para testadores

Quando um recurso está sendo refatorado (considerando que não estamos adicionando nenhuma nova funcionalidade), o entendimento é que, depois que as alterações necessárias forem feitas, a maioria da funcionalidade para o usuário final deve permanecer a mesma.

  • Como um testador, a refatoração de código se traduz aproximadamente em = teste em profundidade + teste de regressão. Os testes aprofundados precisam incluir todos os fluxos de usuário existentes para garantir que todas as funcionalidades estejam funcionando como antes. Teste de regressão de todo o aplicativo (ou áreas impactadas) é necessário para garantir que a atualização de um módulo não interrompa inadvertidamente a funcionalidade dos outros módulos.
  • Os testes de aceitação do usuário serão importantes e esses testes precisam passar antes que o build possa ser declarado pronto para lançamento.
  • Além disso, qualquer outro teste necessário, como testes de carga, teste de segurança etc. também precisariam ser implementados conforme necessário.

# 3) Engenheiros de teste de automação

A refatoração do código pode causar a falha de scripts de automação funcionais e não funcionais.

Isso pode ocorrer pelos seguintes motivos:

  • Se os objetos de página mudarem como parte do esforço de refatoração e se seus scripts de automação Selenium dependerem dos objetos de página, os scripts falharão e precisarão ser atualizados.
  • Se houver pequenas alterações, ele redireciona aquelas que foram adicionadas ou removidas durante a refatoração, e os scripts de automação existentes falharão e precisarão ser atualizados

É recomendado que os testes de automação funcional sejam configurados apenas quando um recurso estiver estável, caso contrário, isso resultará em muito retrabalho à medida que o recurso evolui.

Sendo um desenvolvedor de testes de automação, os engenheiros de teste de automação também precisam pensar como um desenvolvedor e ter como objetivo criar um código limpo e fácil de manter. A maioria dos IDEs, como IntelliJ IDEA, Eclipse etc., incluem menu de refatoração embutido com métodos de refatoração comumente usados ​​para fácil referência.

Abaixo está uma captura de tela do menu de refatoração no IntelliJ IDEA (Community Edition).

como abrir um arquivo bin do Windows 10

menu de refatoração

# 4) Para leads de teste / leads de QA

  • Pode ser necessário que os Líderes de Teste / Líderes de QA trabalhem junto com o resto da equipe, incluindo desenvolvedores, analista de produto e talvez até mesmo as partes interessadas para garantir que o planejamento de teste para tais projetos seja feito com cuidado.
  • É importante entender a funcionalidade existente. Com base na funcionalidade existente, casos de negócios, fluxos de usuário e testes de aceitação do usuário precisam ser documentados. Quando um código refatorado está sendo testado, todos esses cenários precisam ser validados, junto com o teste de regressão das áreas afetadas.
  • Seja proativo ao planejar a abordagem de teste e planos de teste . Se você antecipar a necessidade de vários ambientes de teste ou novas ferramentas de teste, envie a requisição com antecedência para evitar atrasos após o início da fase de teste.
  • Não hesite em envolver membros da equipe que não sejam do projeto ou usuários finais para contribuir com o teste.

Estudos de caso

Agora discutiremos alguns estudos de caso da vida real nos quais tive a oportunidade de trabalhar diretamente ou contribuir indiretamente.

Estudo de caso # 1

Tarefa: Refatore um módulo para substituir os valores embutidos em código por variáveis ​​e adicione comentários para uma nova ferramenta automatizada de geração de documentação técnica.

Desafios :Sem grandes desafios. O módulo era novo, tinha requisitos funcionais e de aceitação do usuário, fluxos de usuário e casos de teste documentados. Os testes de unidade foram configurados durante o próprio lançamento inicial.

Abordagem de Teste :Os casos de teste para o módulo sendo refatorado e as áreas impactadas relativamente conhecidas foram executados. Quaisquer defeitos foram relatados e resolvidos antes do lançamento.

Estudo de caso # 2

Tarefa :Refatore o procedimento armazenado existente para facilitar o aumento de escala do aplicativo.

O procedimento armazenado neste cenário era um procedimento armazenado mais antigo que foi projetado alguns anos atrás, tendo em mente o requisito de que o aplicativo estava usando seu procedimento armazenado como um aplicativo interno com menos de 10 sessões simultâneas.

Agora a empresa queria comercializar esse aplicativo como Software as a Service (SaaS), com o volume esperado de 300 sessões simultâneas inicialmente.

A equipe fez alguns testes de carga iniciais e concluiu que o sistema quebra com uma carga de 25 sessões simultâneas. A equipe revisou o código e recomendou a refatoração de um core stored procedure existente que permitiria que o aplicativo fosse ampliado e suportasse até 500 sessões simultâneas sem interrupção.

Alguns problemas identificados com este procedimento armazenado foram várias subconsultas em uma única consulta, junções pesadas com visualizações em vez de tabelas, uso de select * em vez de selecionar uma coluna específica, etc. Devido a esses problemas de codificação, o aplicativo estava obtendo mais dados do que isso era realmente necessário, fazendo com que o aplicativo ficasse lento e, eventualmente, travasse.

Desafios:

# 1) Gerente de Projeto / Analista de Produto

  • Recolha de requisitos - Como esse procedimento armazenado era um código legado, não havia requisitos documentados para ele quando o módulo foi projetado pela primeira vez. Também para as iterações feitas nos últimos anos, não havia log de alterações para indicar as regras de negócios e lógicas adicionadas ou removidas do módulo.
  • Cronograma do projeto - Como os requisitos não foram claramente definidos e as dependências de código ainda não foram totalmente identificadas, foi difícil comunicar o cronograma provisório.

# 2) Para desenvolvedores

  • Falta de requisitos e regras de negócios claros.
  • Limpar o código sem perder sua funcionalidade.
  • Áreas impactadas e / ou dependências de código desconhecidas.
  • Incapaz de fornecer estimativas de tempo de desenvolvimento concretas.
  • Precisa criar novos testes de unidade.

# 3) Para testadores

  • A falta de requisitos claros e regras de negócios impactam o planejamento de teste.
  • Planejamento de teste de impacto de áreas impactadas desconhecidas, especificamente para testes de regressão.
  • Incapaz de fornecer estimativas de teste concretas.

# 4) Partes interessadas

  • Falta de requisitos documentados claros e / ou fluxos de usuários + prazos apertados = Maior risco de falha.

A abordagem seguida pela equipe para mitigar riscos e contornar os desafios :

(i) A equipe seguiu uma abordagem colaborativa para reunir os requisitos : Gerente de projeto / analista de produto e testadores trabalharam em estreita colaboração com os usuários finais internos para compreender e documentar a principal funcionalidade e o fluxo do usuário.

Os desenvolvedores também revisaram o código e adicionaram informações relevantes ao documento de requisitos. Isso foi feito antes do dia de início do sprint.

(ii) O ambiente de teste alternativo foi criado para testar a mudança que está sendo implementada : Vamos chamar esses ambientes de Gamma e Phi. Gamma teria o código antigo e Phi teria o procedimento armazenado refatorado mais recente implantado em todos os momentos.

Ter 2 ambientes de teste em paralelo, quase recriando a abordagem antes e depois, permitiu que a equipe fizesse testes mais aprofundados e exploratórios, comparando o comportamento nesses 2 ambientes de teste, eles foram capazes de identificar os prováveis ​​bugs.

A equipe forneceu os requisitos para um ambiente de teste alternativo que foi fornecido antes da data de início do sprint.

(iii) Usuários finais e partes interessadas envolvidas no teste desde o início : Quaisquer problemas óbvios foram detectados e relatados no início, permitindo mais tempo para a equipe implantar e testar a correção necessária.

(iv) Definição de critérios de saída e aderência a eles: Os critérios de saída foram definidos nos estágios iniciais de planejamento - 80% dos fluxos de usuários testados, nenhum bug crítico não resolvido, demonstração e aprovação das partes interessadas antes do lançamento.

(v) Definir uma data de lançamento provisória: Definir uma data de lançamento alinhada e motivar a equipe a trabalhar para um endpoint comum. Com base no escopo do projeto, foi recomendado pela equipe que um sprint de 3 semanas fosse seguido em vez de um sprint normal de 2 semanas para permitir tempo suficiente para a equipe executar o projeto.

Conclusão

Para resumir, a refatoração de código é um processo para limpar / simplificar o design de um módulo sem alterar sua funcionalidade. O processo de refatoração pode ser simples, como adicionar comentários, adicionar indentação correta, remover uma variável estática, etc. ou pode ser complicado para sistemas legados complexos.

Um módulo ou parte do código em particular pode precisar ser refatorado por causa do cheiro do código, dívida técnica ou por seguir uma abordagem ágil de desenvolvimento de software.

Para os testadores, a refatoração do código se traduz aproximadamente em = teste em profundidade + teste de regressão.

Um teste aprofundado é necessário para testar todos os fluxos de usuário existentes para garantir se todas as funcionalidades estão funcionando como antes. O teste de regressão de todo o aplicativo (ou áreas impactadas) é necessário para garantir que a atualização de um módulo não interrompa acidentalmente a funcionalidade dos outros módulos.

Pode ser necessário que os Líderes de Teste / Líderes de QA trabalhem junto com o resto da equipe, incluindo desenvolvedores, Analista de produto, especialmente para projetos legados. Seja proativo ao planejar a abordagem e os planos de teste. Se você antecipar a necessidade de vários ambientes de teste ou novas ferramentas de teste, envie a requisição com antecedência para evitar atrasos após o início da fase de teste.

Sobre o autor: Este tutorial informativo foi escrito por Neha B. Ela está atualmente trabalhando como Gerente de Garantia de Qualidade e é especializada em liderar e gerenciar equipes de QA internas e offshore.

Você trabalhou em um projeto desafiador que envolvia refatoração de código ou um módulo / aplicativo? Se sim, sinta-se à vontade para compartilhar suas experiências na seção de comentários para que nossos outros testadores possam aprender.

Leitura recomendada

^