SkillEngenhariaEstruturação

Fatiamento de Refatoração e Planejamento de PRs

Fatia a estratégia de refatoração para a arquitetura alvo em incrementos tangíveis, seguros e progressivos (sprints e PRs).

Em:Planejamento de Refatoração e Arquitetura Alvo
Ações
PerfilDev
ProfundidadeAlta
Idiomapt-BR
Objetivo

Em uma frase.

Fatiar a transição entre o estado inicial e a arquitetura alvo delimitada em ciclos curtos de modificação sistêmica garantindo total estabilidade na branch principal através de uma linha do tempo orquestrada de Pull Requests independentes ou Sprints.

Aplicação

Quando
faz sentido.

Usar
  • Ao transformar o Documento de Arquitetura Alvo e o Gap Analysis em roteiro de execução prática (PRs a serem criados).
  • Como as etapas finais no workflow de Planejamento de Refatoração e Arquitetura Alvo.
  • Em refatorações extensas (semanas/meses) onde ficar travado em uma feature-branch gigantesca não é uma opção.
Não usar
  • Em refatorações focadas estritamente em extração/renomeio com menos de 2h de esforço total e apenas 1 commit óbvio.
  • Quando a arquitetura final não foi definida ou aprovada.
Prompt

Instruções
para a IA.

Passo 1 — Dividir o Gap em Mudanças Lógicas Verticais ou Horizontais

Examine o diferencial de Arquitetura. Identifique blocos de mudanças que podem ser tratados com independência sistêmica:

- É possível refatorar uma entidade inteira através da camada desde a DB até o endpoint sem ferir outra? (Fatia puramente vertical). - É necessário extrair globalmente uma camada "core" genérica como alicerce antes? (Fatia horizontal de fundação). - Onde a aplicação antiga e a nova vão coexistir temporalmente antes das lógicas legadas serem depravadas? (Exemplo: Strangler Fig Pattern).

Passo 2 — Estruturar Blocos por Categoria de Mudança

Mapear se a etapa é de **Preparação**, **Criação de Fundações/Infraestrutura Alvo**, **Migração Progressiva de Lógica**, **Abertura/Chaveamento (Feature Toggle)** ou **Limpeza Pós-Migração**. Siga o princípio de Expand & Contract (expansão da capacidade nova e retração/extinção silenciosa do legado após testes e veracidade).

### Passo 3 — Construir as Fatias (PRs Atômicos de Integração Segura)

Transforme essas lógicas numa esteira granular de Pull Requests (PRs). Para cada PR no plano, extrair:

- **Título do PR esperado e objetivo explícito** (ex: Implementa a infraestrutura abstrata UserRepository usando Ports & Adapters mas inda não a utiliza na Main). - **Alterações Planejadas no código.** - **Rollback em falha:** O que será estourado ou desligado se a fatia se mostrar mal planejada? - **Integração de Continuidade (CD):** A Main/Master pós-PR continua íntegra e deployável sem erros mesmo nos ambientes não refatorados? - **Riscos associados.**

Passo 4 — Validar a Ordem contra o Diagnóstico Inicial de Dívida

Reveja as ordens da esteira e garanta que:

- Fatias de refatoração para regiões mapeadas no top 3 do ranking de dívidas urgentes são atacadas de imediato onde possível (ou exigem uma fundação imediata clara). - Nenhuma fatia gera aumento brusco temporário da instabilidade do componente durante a "Fase C". Todos os estágios intermediários são transitórios e cobertos.

### Passo 5 — Documentar esteira Completa de PRs ou Sprints

Registre a timeline formatada que deverá servir como quadro mestre/jira/backlog da equipe técnica de execução da refatoração.

---
Constelação

Onde
ela vive.

Workflows que usam
Bundles que incluem