No contexto das metodologias ágeis, o conceito de refatoração compreende
- A)a renomeação de atributos e métodos para implementar melhorias no software.
Correta, porque renomear atributos e métodos para melhorar clareza e manutenção é um exemplo clássico de refatoração, sem mudar o comportamento externo.
- B)a decomposição de histórias de usuário em uma série de tarefas de desenvolvimento.
Errada, porque decompor histórias de usuário em tarefas é atividade de planejamento e detalhamento do trabalho, não refatoração.
- C)a substituição do resultado de uma sprint inteira para atender a requisitos diferentes dos originais.
Errada, porque substituir o resultado de uma sprint para atender novos requisitos é mudança de escopo ou replanejamento, não refatoração.
- D)a junção de alterações de código às funcionalidades do software já entregue.
Errada, porque unir alterações de código às funcionalidades já entregues se aproxima de integração ou evolução do produto, não da ideia de refatorar a estrutura interna.
- E)o desenvolvimento de testes incrementais a partir de novos cenários.
Errada, porque desenvolver testes incrementais a partir de novos cenários é prática de teste, especialmente em abordagem incremental, e não refatoração.
Gabarito: A
Refatoração, nas metodologias ágeis, é o ato de melhorar a estrutura interna do código sem mudar o comportamento externo do sistema. Em outras palavras: o software continua fazendo a mesma coisa, mas fica mais limpo, mais fácil de entender e mais fácil de manter. É como organizar um armário sem trocar as roupas de lugar no sentido prático: a função final não muda, mas a bagunça diminui. Esse conceito é muito ligado à manutenção da qualidade do código e aparece com força em práticas como TDD e Extreme Programming. A ideia é mexer em nomes, dividir trechos confusos, simplificar lógica e remover duplicações, sempre preservando os testes e o funcionamento esperado. Não é criar nova funcionalidade nem reescrever o produto para atender outro requisito; é lapidar o que já existe. Por isso o gabarito é a alternativa A: renomear atributos e métodos pode ser uma forma clássica de refatoração, desde que a alteração tenha o objetivo de melhorar a legibilidade, a organização ou a manutenção do software, sem alterar seu comportamento. A banca costuma cobrar justamente essa essência: mudar a estrutura interna, mas não a regra de negócio entregue ao usuário. Se a questão falar em decompor, juntar, substituir sprint ou criar testes para novos cenários, desconfie. Isso pode parecer relacionado ao desenvolvimento ágil, mas não define refatoração. Refatorar é arrumar o código existente, não trocar o problema por outro.