Cada desarrollador tiene esa carpeta. Esa llamada utils o helpers que copias de un repositorio a otro. La pegas, pasas veinte minutos eliminando referencias a esquemas de bases de datos antiguos, quitando comprobaciones de autenticación que no aplican y renombrando variables para que tu nuevo linter deje de gritar. Yo solía hacer esto con un sistema de tematización que había construido, el Dynamic Theme Kit. Comenzó como una funcionalidad dentro de una aplicación y, durante meses, lo traté como una herramienta portátil. Me equivoqué. Copiar código no es reutilizar. Es duplicar con pasos adicionales.

La trampa de la mentalidad de un solo proyecto

Cuando construyes una funcionalidad dentro de un proyecto, haces cientos de suposiciones invisibles. La paleta de colores podría asumir una configuración específica de CSS-in-JS. La escala de espaciado podría hacer referencia a un token de diseño de la guía de marca de tu empresa. El interruptor entre el modo claro y oscuro podría llamar a un endpoint de preferencias de usuario único del backend de esa aplicación. Estas dependencias parecen inofensivas porque, dentro del proyecto, lo son. Pertenecen allí.

El problema comienza cuando intentas extraer ese código. Descubres que el componente "reutilizable" es en realidad una red de cadenas ocultas que lo conectan a esa única base de código. Aprendí esto con DTK. Generaba variables de tema, sí. Pero también esperaba una estructura de carpetas específica. Importaba una definición de tipo desde algún lugar profundo en el directorio de tipos de la aplicación original. Asumía la presencia de un objeto de configuración global que solo existía en ese repositorio. Nunca lo había notado porque, dentro de ese proyecto, todo estaba siempre presente.

Convertir DTK en un paquete independiente significó una cirugía, no una expansión. No necesitaba más funcionalidades. Necesitaba menos conexiones.

Extrayendo el Dynamic Theme Kit

El trabajo más difícil fue sentarse con la base de código y preguntar, por cada función y cada exportación: ¿esto sirve a la lógica de tematización o sirve al proyecto? Eliminé los ajustes preestablecidos de estilo. Eliminé la suposición de que el consumidor sería una aplicación React. Borré por completo las paletas de colores por defecto. El proyecto original tenía una estética corporativa en azul marino y pizarra integrada en los valores predeterminados. Eso tenía que desaparecer. Un paquete no puede incluir los colores de tu marca.

El nuevo kit haría exactamente una cosa. Toma un objeto de configuración —algunos valores de color, algunos números de espaciado, algunas escalas tipográficas— y genera propiedades personalizadas de CSS. Eso es todo. No las aplica. No decide dónde van en tu DOM. No le importa si usas Tailwind, Styled Components o HTML puro. Le entrega las variables a tu aplicación, y tu proyecto elige cómo usarlas.

Esa restricción se sintió limitante al principio. Resultó ser liberadora.

Qué se rompe cuando realmente intentas reutilizarlo

Antes de publicar nada, necesitaba pruebas de que la abstracción realmente funcionaba. Saqué tres pequeños proyectos personales de mi archivo: una herramienta de vista previa de markdown, un rastreador de hábitos y una landing page para un evento. Ninguno compartía un framework o una estructura de carpetas. Instalé DTK localmente en cada uno e intenté tematizarlos.

El primer intento falló de inmediato. Los nombres de las variables que generaba DTK eran demasiado específicos. Estaba emitiendo tokens como --primary-action y --background-overlay que implicaban un determinado diseño de interfaz de usuario. En el visor de markdown, esos nombres no tenían sentido. No había un botón de acción. No había una superposición. Renombré la lógica de generación para producir nombres estructurales y neutros que describieran el valor en lugar del widget.

También descubrí que mis valores por defecto eran demasiado agresivos. Cuando un usuario pasaba una configuración incompleta, DTK rellenaba los huecos con valores que parecían estar bien en un dashboard denso, pero que rompían en una landing page minimalista. Cambié a valores por defecto transparentes donde los tokens faltantes simplemente no se renderizaban, permitiendo que el proyecto que los consume defina sus propios fallbacks.

Luego estaba la documentación. Lo que me parecía obvio —"solo pasa un objeto de configuración"— era vago para alguien que leía el README a medianoche. Lo reescribí con objetos reales, rutas de archivos reales y explicaciones claras de lo que sucede cuando llamas a la función frente a lo que tu aplicación debe hacer después.

Estos pequeños proyectos personales actuaron como bancos de prueba. No tenían mucho en juego, pero expusieron fallos reales que no habría detectado mirando el código fuente de forma aislada.

La verdadera prueba: Producción en Web Weavers World

Los proyectos personales son entornos de prueba. No tienen fechas límite, partes interesadas ni CSS heredado que sea anterior a tu paquete. La verdadera prueba llegó cuando integré DTK en Web Weavers World, mi sitio de negocios. Esta era una propiedad en vivo con estilos existentes, expectativas del cliente y analíticas a considerar. Si el paquete rompía algo, no podía simplemente borrar el repositorio y empezar de nuevo.

Añadí DTK al pipeline de construcción, lo apunté a una nueva configuración de colores y dejé que generara un nuevo conjunto de variables CSS. La integración tomó una tarde, no una semana. Esa fue la señal. Anteriormente, añadir un nuevo tema significaba escribir nuevo CSS, rastrear valores hexadecimales codificados directamente en veinte archivos y esperar no haber pasado por alto ningún caso extremo. Ahora añado una paleta al archivo de configuración, DTK genera las variables y el resto del sitio las consume. La lógica del tema pasó de ser un proceso manual frágil a algo en lo que confío lo suficiente como para delegarlo a colaboradores.

Tres preguntas que cambiaron mi forma de construir

Pasar por este proceso me obligó a formalizar una lista de verificación mental que ahora utilizo antes de abstraer cualquier cosa:

  • ¿Es esta variable realmente genérica? Si el nombre o la lógica hace referencia a un concepto de dominio del proyecto original, se queda atrás.
  • ¿Pertenece esto al paquete o a la aplicación? Las reglas de negocio, las identidades de marca y las suposiciones de diseño residen en la aplicación. La infraestructura que genera una salida estandarizada reside en el paquete.
  • ¿Estoy resolviendo un problema reutilizable o uno específico de un proyecto? Esta es la más difícil de responder con honestidad. Nos gusta pensar que nuestras soluciones son universales. Por lo general, son locales.

Responder a estas preguntas me obligó a simplificar mi diseño, a menudo eliminando código en lugar de añadirlo. DTK me enseñó que la reutilización no es un regalo que te haces a ti mismo. Es una disciplina que practicas diciendo no a la conveniencia.

Una forma diferente de pensar en la refactorización

Antes medía las refactorizaciones por cuánto acortaban el código. Menos líneas se sentían como progreso. Ahora las mido por cuántas puertas abren. El Dynamic Theme Kit no es elegante por ser conciso. Es útil porque sobrevivió a tres proyectos personales no relacionados y a un sitio de negocios en producción sin necesidad de cambiar su estructura interna.

Esa es la métrica que importa. El código que funciona una vez es un gasto. El código que funciona repetidamente es un activo. Antes de empezar cualquier funcionalidad ahora, me detengo. Me pregunto si estoy construyendo algo que necesitaré de nuevo. Si la respuesta es sí, lo construyo de forma diferente desde la primera línea. Aíslo las entradas. Defino las salidas. Elimino las suposiciones.

La mejor refactorización no hace que tu código sea más corto. Hace que tu código funcione en lugares que aún no has imaginado.