Descontinuando componentes do sistema de design sem interromper as equipes de produto
Como implementar mudanças inovadoras no sistema de design em aplicativos grandes: anunciar, descontinuar, migrar com codemods e remover, usando controle de versão semântico e rastreamento de uso.
Ponto principal
Descontinuar um componente em quatro etapas: anunciar a mudança com o motivo e a substituição, marcar o componente antigo como obsoleto em uma versão secundária com avisos claros, ajudar as equipes a migrar com guias e codemods automatizados e removê-lo somente na próxima versão principal. Acompanhe quantas telas ainda o utilizam em cada etapa e não o remova até que o uso esteja próximo de zero.
Por que a depreciação dá errado
As mudanças no sistema de design falham quando surpreendem as equipes de produto: um componente desaparece em uma atualização, as compilações são interrompidas e as equipes fixam a versão antiga e param de atualizar. Quando isso acontece, o sistema perde seu principal benefício, a consistência, porque diferentes partes do produto derivam para versões diferentes.
Um processo de quatro etapas
O versionamento semântico oferece um contrato simples: alterações incompatíveis vão para uma versão principal e, quando você descontinuar parte de uma API, você deve atualizar a documentação e enviar uma versão secundária com a descontinuação em vigor, antes de removê-la posteriormente.
- Anuncie: explique o porquê, mostre o substituto, dê um cronograma.
- Obsoleto: marque-o nos documentos e no código, com um aviso de console ou lint vinculado ao guia.
- Migrar: forneça um guia escrito e, para código, um codemod que atualize os usos automaticamente.
- Remover: na próxima versão principal, quando o uso estiver próximo de zero.
Automatize a migração
Codemods são scripts que reescrevem o código em uma base de código. Ferramentas como jscodeshift executam codemods em muitos arquivos JavaScript ou TypeScript de uma só vez, portanto, uma renomeação de prop ou troca de componente pode ser aplicada em minutos em vez de semanas. Combine-os com regras de lint que sinalizam os usos restantes.
Adoção de medidas
Você não pode planejar a remoção sem saber quem ainda usa um componente. Rastreie o uso em código (importações, avisos de lint) e em arquivos de design (análise de biblioteca em sua ferramenta de design). Publique os números para que as equipes possam ver o progresso e ajude as últimas equipes diretamente, em vez de forçar um prazo.
Não se esqueça do lado do design
Suspenda também o componente na biblioteca de design: renomeie-o com um prefixo "Obsoleto", vincule-o ao substituto e pare de aparecer na pesquisa. Caso contrário, os designers continuarão a usá-lo em novos trabalhos e a migração nunca terminará. O comportamento de movimento e interação deve fazer parte das notas de mudança, porque um substituto que se move de maneira diferente pode parecer quebrado mesmo que pareça igual.
Princípios-chave para lembrar
- Anuncie, descontinuar, migrar, remover: nunca vá direto para a remoção
- Obsoleto em uma versão secundária; remover em uma versão principal
- Use codemods e regras lint para automatizar a migração
- Rastreie o uso em arquivos de código e design
- Incluir alterações de movimento e interação nas notas de lançamento
Perguntas frequentes
Fontes
- Semantic Versioning 2.0.0 — semver.org
- jscodeshift: a JavaScript codemod toolkit — GitHub (meta)