--- title: "Um plano de 30 dias para modernizar apps Angular maduros" description: "Uma sequência de modernização para times que precisam de auditoria, mudanças de baixo risco, spikes isolados e decisões que sobrevivem a code review." deck: "Se modernizar Angular parece vago demais, coloque no calendário: auditoria primeiro, mudanças pequenas depois, ideias arriscadas em branch e decisões por escrito. Com o Angular soltando [um major a cada seis meses](https://angular.dev/reference/releases) e cinco majors entre v16 e v21, uma sequência escrita é o que impede a modernização de virar campanha." author: "André Ramos" url: "https://andreramos.dev/pt/angular/angular-30-day-modernization-plan/" lang: "pt-BR" type: "article" --- # Um plano de 30 dias para modernizar apps Angular maduros > Se modernizar Angular parece vago demais, coloque no calendário: auditoria primeiro, mudanças pequenas depois, ideias arriscadas em branch e decisões por escrito. Com o Angular soltando [um major a cada seis meses](https://angular.dev/reference/releases) e cinco majors entre v16 e v21, uma sequência escrita é o que impede a modernização de virar campanha. ## Dias 1-3: auditoria antes de opinião Rode `ng version`, registre Angular, CLI, TypeScript, Node, RxJS, Material/CDK, builders, test runner e dependências críticas de terceiros. Rode build de produção e testes. Liste warnings antes de corrigir. O [update guide oficial](https://angular.dev/update-guide) é a segunda aba certa pra deixar aberta, já que customiza por versão de origem, versão alvo, complexidade e dependências tipo ngUpgrade ou Material. Procure dependências de Zone.js, subscriptions manuais, timers, NgModules, SharedModules grandes, reactive forms, fronteiras de NgRx e bibliotecas que mexem muito no DOM. A saída é um documento curto de baseline. Se o primeiro PR já muda comportamento, a auditoria chegou tarde. *Início de docs/angular-modernizacao-2026.md* ```text # Baseline de modernização Angular Angular / CLI: Node / TypeScript / RxJS: Comando de build: Comando de teste: Bloqueadores conhecidos: Primeiro piloto de baixo risco: Explicitamente fora de escopo: ``` ## Dias 4-13: alinhamento de baixo risco Comece alinhando o código novo aos padrões atuais do Angular. Use [standalone](https://angular.dev/guide/components) em componentes novos isolados, [control flow moderno](https://angular.dev/guide/templates/control-flow) em templates já alterados e [Signals](https://angular.dev/guide/signals) para estado local onde reduzem boilerplate. A [documentação oficial de migração standalone](https://angular.dev/reference/migrations/standalone) é explícita sobre a rede de segurança: 'Existing applications can optionally and incrementally adopt the new standalone style without any breaking changes.' Essa postura é o que torna o trabalho das semanas 1-2 viável. Schematics como `ng generate @angular/core:standalone` e `ng generate @angular/core:control-flow` cobrem a parte mecânica; o review do time fica focado no padrão a repetir. Não converta a aplicação inteira só para defender uma tese. O objetivo é um padrão repetível que o time consiga revisar. Se o segundo PR é difícil de explicar, o padrão ainda não está pronto. ## Dias 14-23: spikes controlados | Spike | Pergunta | Evidência | |---|---|---| | Zoneless | Quais fluxos quebram quando change detection fica explícita? | Smoke tests para timers, forms, subscriptions, overlays e charts. | | Vitest | Uma fatia da suíte roda mais rápido sem quebrar tooling? | CI com specs migradas e diferenças conhecidas de mocks/fake timers. | | SSR/hydration | Rotas públicas precisam de renderização no servidor? | Baseline de web vitals, auditoria de DOM e teste de hydration. | | Signal Forms | Existe uma tela de baixo risco onde o experimento ensina o time? | Branch isolada com docs atuais, sem dependência crítica de produção. | ## Entregáveis por semana O plano só é útil se toda semana deixa algo que o time consegue revisar. Eu não mediria pelo número de APIs tocadas; mediria por quanto o próximo reviewer consegue decidir com menos risco. | Semana | Entregável | Pergunta de review | |---|---|---| | Semana 1 | Baseline técnico | Sabemos versões, bloqueadores, padrões de risco e comandos? | | Semana 2 | PR piloto | Um padrão de baixo risco melhorou ownership sem churn amplo? | | Semana 3 | Relatórios de spike | Falhas, timings e rollback vieram do app real? | | Semana 4 | ADRs e backlog | O time sabe o que vira default, fica adiado ou sai de escopo? | ## Dias 24-30: decidir e documentar A última semana não é para adicionar mais experimentos. É para escrever decisões: o que vira default em código novo, o que será migrado quando tocar, o que precisa de mais evidência e o que explicitamente não vai acontecer agora. A saída deve ser simples e explícita: control flow aprovado para templates já alterados, zoneless adiado depois de falhas em overlay, Signal Forms bloqueado em forms críticos enquanto a API for experimental, Vitest liberado só em pacote piloto até o CI trazer dados melhores. Uma ADR curta basta. Inclua contexto, decisão, escopo, fora de escopo, riscos e comandos de validação. Isso importa porque modernização fica cara quando cada reviewer precisa redescobrir a mesma decisão. *Template curto de ADR* ```text # ADR: usar Signals para estado local em componentes novos Status: proposta Contexto: app existente, padrões mistos para estado local, sem uso de Signals Decisão: adotar Signals locais em componentes novos e tocados; manter RxJS para streams assíncronos Escopo: código novo e features de baixo risco que já vão mudar Fora de escopo: substituir NgRx, services ou streams assíncronos Riscos: mau uso de effect, padrões mistos, reescrita acidental Validação: testes, smoke flow, checklist de code review ``` ## Artefato reaproveitável: Sequência de 30 dias - Dias 1-3: auditar versões, testes, CI, dependências e padrões de risco. - Dias 4-13: entregar um PR piloto de baixo risco que reviewers conseguem repetir. - Dias 14-23: rodar spikes isolados para zoneless, Vitest, SSR e APIs experimentais. - Dias 24-30: escrever ADRs, itens de backlog e não-objetivos explícitos. ## Fontes consultadas - https://angular.dev/reference/releases - https://angular.dev/update-guide - https://angular.dev/reference/migrations - https://angular.dev/reference/migrations/standalone - https://angular.dev/reference/migrations/control-flow - https://angular.dev/reference/migrations/inject-function - https://angular.dev/reference/migrations/signal-inputs - https://angular.dev/guide/components - https://angular.dev/guide/signals - https://angular.dev/guide/templates/control-flow - https://angular.dev/guide/zoneless - https://angular.dev/guide/testing/migrating-to-vitest - https://angular.dev/guide/forms/signals/overview ## Leia também - [Um checklist curto antes de testar zoneless](https://andreramos.dev/pt/angular/zoneless-checklist/) - [Standalone sem transformar NgModules em vilões](https://andreramos.dev/pt/angular/standalone-without-ngmodule-dogma/) - [O que adotar, testar ou deixar para depois no Angular 21](https://andreramos.dev/pt/angular/adopt-spike-wait-angular-21/)