request-refactor-plan

Sobre o request-refactor-plan

O request-refactor-plan é uma habilidade de planejamento em língua chinesa (traduzida) da coleção mattpocock-skills-zh-cn (caminho obsoleto), que entrevista o usuário para elaborar um plano detalhado de refatoração dividido em pequenos commits, sendo posteriormente arquivado como um issue no GitHub. O problema que ela resolve é o risco associado a refatorações em grande escala realizadas em etapas extensas; essa habilidade aplica passos incrementais e sempre funcionais, seguindo o conselho de Martin Fowler de tornar cada etapa de refatoração o mais pequena possível, para que seja possível verificar constantemente se o programa está funcionando.

O procedimento (os passos podem ser pulados) é o seguinte: fazer com que o usuário descreva o problema e as soluções possíveis; explorar o repositório para verificar suas afirmações e entender o estado atual; apresentar opções alternativas; entrevistar o usuário detalhadamente sobre a implementação; definir com precisão o escopo, incluindo o que será e o que não será alterado; verificar a cobertura de testes na área afetada e questionar os planos de teste caso ela seja insuficiente; dividir a implementação em um plano de pequenos commits, cada um mantendo o códigobase em estado funcional; e, por fim, criar um issue no GitHub usando um modelo fornecido, com seções para Declaração do Problema, Solução, Commits, Documento de Decisão, Decisões de Teste, Fora do Escopo e, opcionalmente, Observações Adicionais. O modelo evita deliberadamente caminhos de arquivos concretos e trechos de código, pois eles se tornam rapidamente desatualizados.

Ela é voltada para desenvolvedores e líderes técnicos que planejam refatorações ou elaboram RFCs de refatoração e desejam um plano rigoroso, baseado em entrevistas e incremental, registrado como um issue duradouro. Seu funcionamento consiste na exploração do repositório mais na criação de issues — sem operações destrutivas ou sensíveis.

Perguntas Frequentes

O que essa habilidade cria?

Um plano detalhado de refatoração registrado como um issue no GitHub, utilizando um modelo com Declaração do Problema, Solução, Commits, Documento de Decisão, Decisões de Teste, Fora do Escopo e, opcionalmente, Observações Adicionais.

Como ela garante a segurança da refatoração?

Ela divide o trabalho em pequenos commits, cada um mantendo o códigobase em estado funcional, seguindo as orientações de Martin Fowler de tornar cada etapa de refatoração o mais pequena possível.

O plano faz referência a arquivos ou código específicos?

Não. O modelo omite intencionalmente caminhos de arquivos concretos e trechos de código, pois eles se tornam rapidamente desatualizados; ele se concentra em decisões, módulos, interfaces e comportamentos.

O que ela faz em relação aos testes?

Ela verifica a cobertura de testes na área afetada e, caso a cobertura seja insuficiente, questiona o usuário sobre seus planos de teste, registrando em seguida as decisões relacionadas aos testes no issue.

Quais são os pré-requisitos?

Um repositório para ser explorado e usado como base para a entrevista, além da capacidade de criar um issue no GitHub com o plano finalizado.