Refactorizar alrededor de una frontera
Cambia la estructura de un programa manteniendo estables sus promesas públicas.
AL TERMINAR, PODRÁS
- Distinguir un refactor de un cambio de comportamiento
- Identificar acoplamiento y cohesión
- Introducir una frontera de almacenamiento sin abstracciones especulativas
Descripción del diagrama: Quienes llaman → Función pública (llaman); Los tests fijan el comportamiento → Función pública; Función pública → Interior anterior (antes); Función pública → Interior nuevo (después)
Conserva una promesa mientras cambias su forma
Refactorizar (refactoring) es cambiar la estructura interna sin cambiar a propósito el comportamiento observable.
Es más fácil cuando ese comportamiento está cubierto por pruebas (tests) y un contrato claro. Supón que Relay guarda los trabajos en un diccionario hoy, pero mañana necesitará una base de datos. Primero identifica las operaciones de las que dependen quienes lo usan: encolar, reservar (claim) y avisar que terminó (acknowledge, ack).
Una frontera construida alrededor de esas operaciones es más estable que exponer el diccionario por todas partes. No combines una reescritura amplia, funcionalidades nuevas y cambios de contrato a menos que puedas revisar sus efectos por separado.
Sigue las razones para cambiar
Cohesión significa que el comportamiento relacionado vive junto.
Acoplamiento (coupling) significa que una parte conoce los detalles de otra. Si cambiar el almacenamiento requiere editar la validación de entrada, la planificación y el formato de salida, los detalles del almacenamiento se han extendido demasiado. Mueve ese conocimiento detrás de una interfaz pequeña y pasa la dependencia a quien la usa.
Mantén las decisiones de negocio independientes de la mecánica de la base de datos cuando sea práctico. Esto no es una invitación a crear una interfaz para cada clase. Introduce una costura (seam) donde tengas una variación concreta, una necesidad de pruebas o una fuente de cambio.
Da pasos pequeños y reversibles
Empieza por extraer una operación con nombre sin alterar su lógica.
Ejecuta las comprobaciones relevantes. Redirige a un solo usuario de esa lógica a través de la nueva frontera y repite. Cuando todos la usen, elimina los caminos obsoletos.
Examina si el nuevo diseño realmente redujo el conocimiento necesario y facilitó el siguiente cambio. Un diseño con más capas puede estar aún más acoplado si esas capas solo reenvían detalles de implementación. En Relay, un repositorio que expone los cursores crudos de la base de datos a todos sus usuarios no ha ocultado del todo las decisiones de almacenamiento.
ERROR FRECUENTE
Una abstracción que copia cada método de una única implementación suele conservar su acoplamiento y además agrega navegación.
INTÉNTALO TÚ
Encuentra cada lugar donde un worker de juguete manipula directamente los trabajos pendientes. Propón tres operaciones que expresen la intención sin exponer la colección que hay debajo.
Decide en el laboratorio.
El checkpoint de dos preguntas, tus notas y tu progreso guardado están en el laboratorio. Gratis y sin cuenta.
Abrir en el laboratorio ↗CONÉCTALO CON RELAY
Introduce en Relay una frontera de almacenamiento con una implementación en memoria. Deja la política de planificación fuera de la mecánica de almacenamiento.