Dejar obsoletos los componentes del sistema de diseño sin romper los equipos de productos
Cómo implementar cambios importantes en el sistema de diseño en aplicaciones grandes: anunciar, desaprobar, migrar con codemods y eliminar, utilizando control de versiones semántico y seguimiento de uso.
Idea clave
Retire un componente en cuatro pasos: anuncie el cambio con el motivo y el reemplazo, marque el componente antiguo como obsoleto en una versión menor con advertencias claras, ayude a los equipos a migrar con guías y codemods automatizados, y elimínelo solo en la próxima versión principal. Realice un seguimiento de cuántas pantallas todavía lo utilizan en cada paso y no lo elimine hasta que el uso sea cercano a cero.
Por qué la desaprobación sale mal
Los cambios en el sistema de diseño fallan cuando sorprenden a los equipos de producto: un componente desaparece en una actualización, las compilaciones se interrumpen y los equipos fijan la versión anterior y dejan de actualizar. Una vez que eso sucede, el sistema pierde su principal beneficio, la coherencia, porque diferentes partes del producto derivan en diferentes versiones.
Un proceso de cuatro pasos
El control de versiones semántico ofrece un contrato simple: los cambios incompatibles se incluyen en una versión principal, y cuando se desaproba parte de una API, se debe actualizar la documentación y enviar una versión menor con la desaprobación vigente, antes de eliminarla más adelante.
- Anuncie: explique por qué, muestre el reemplazo, proporcione un cronograma.
- En desuso: márquelo en documentos y en código, con una consola o advertencia de pelusa que enlace a la guía.
- Migrar: proporcione una guía escrita y, para el código, un codemod que actualice los usos automáticamente.
- Eliminar: en la próxima versión principal, una vez que el uso sea cercano a cero.
Automatizar la migración
Codemods son scripts que reescriben código en una base de código. Herramientas como jscodeshift ejecutan codemods en muchos archivos JavaScript o TypeScript a la vez, por lo que se puede aplicar un cambio de nombre de accesorio o intercambio de componentes en minutos en lugar de semanas. Combínelos con reglas de pelusa que marquen los usos restantes.
Adopción de medidas
No se puede planificar la eliminación sin saber quién sigue utilizando un componente. Realice un seguimiento del uso en el código (importaciones, advertencias de pelusa) y en los archivos de diseño (análisis de biblioteca en su herramienta de diseño). Publique los números para que los equipos puedan ver el progreso y ayude a los últimos equipos directamente en lugar de imponer una fecha límite.
No te olvides del lado del diseño.
Deje obsoleto el componente también en la biblioteca de diseño: cámbiele el nombre con un prefijo "Obsoleto", vincúlelo al reemplazo y deje de aparecer en la búsqueda. De lo contrario, los diseñadores siguen usándolo en nuevos trabajos y la migración nunca termina. El comportamiento de movimiento e interacción debe ser parte de las notas de cambio, porque un reemplazo que se mueve de manera diferente puede parecer roto incluso si luce igual.
Principios clave para recordar
- Anunciar, desaprobar, migrar, eliminar: nunca saltar directamente a la eliminación
- Desaprobar en una versión menor; eliminar en una versión importante
- Utilice codemods y reglas de pelusa para automatizar la migración
- Seguimiento del uso tanto en código como en archivos de diseño
- Incluir cambios de movimiento e interacción en las notas de la versión.
Preguntas frecuentes
Fuentes
- Semantic Versioning 2.0.0 — semver.org
- jscodeshift: a JavaScript codemod toolkit — GitHub (meta)