Escribir código limpio no es solo una buena práctica, es lo que marca la diferencia entre un proyecto mantenible y uno que se vuelve inmanejable con el tiempo. Los principios SOLID ofrecen una guía clara para estructurar mejor el software, y cuando se combinan con patrones como los custom hooks de React, el resultado es un código más fácil de entender, escalar y, sobre todo, testear.
¿Qué significan los principios SOLID con ejemplos cotidianos?
SOLID es un acrónimo que agrupa cinco principios fundamentales del desarrollo de software [0:02]. Cada letra representa una regla que, llevada a la práctica, mejora la calidad del código:
- S — Responsabilidad única: un chef solo cocina, no limpia ni cobra. Cada clase o función debe tener una sola razón para cambiar.
- O — Abierto/cerrado: puedes añadir aplicaciones a tu celular sin dañar las existentes. El código debe ser extensible sin necesidad de modificar lo que ya funciona.
- L — Sustitución de Liskov: si pides un taxi, cualquier conductor puede llevarte. Los componentes deben ser intercambiables sin alterar el comportamiento del sistema.
- I — Segregación de interfaces: mejor un control de televisión simple que uno universal confuso. Las interfaces deben ser específicas y desacopladas.
- D — Inversión de dependencias: como una USB que puedes conectar en cualquier puerto compatible. Los módulos de alto nivel no deben depender de los de bajo nivel.
Estos principios no aplican solo al testing, sino a todo el mundo del software [0:27]. Seguirlos conduce a lo que se conoce como clean code, que es el factor que más aporta seniority en el desarrollo profesional.
¿Por qué extraer lógica a un custom hook mejora la testeabilidad?
En el contexto del testing, entre más atómicos sean los componentes y las funciones, más sencillo será escribir pruebas para ellos [0:48]. Cuando toda la lógica vive dentro de un solo componente de React, se vuelve difícil aislar comportamientos para probarlos de forma independiente.
El componente de orders del proyecto tenía todo mezclado: creación de estados, conexión a stores, ciclos de vida y funciones [1:01]. La solución es aplicar el principio de responsabilidad única extrayendo esa lógica a un custom hook.
¿Cómo se crea el custom hook useOrders paso a paso?
El proceso comienza creando una carpeta hooks dentro de src y un archivo llamado useOrders.js [1:24]. Luego se identifican las líneas de lógica que deben moverse desde el componente:
- Los estados con
useState.
- Los ciclos de vida con
useEffect.
- Las funciones como
fetchOrders optimizadas con useCallback.
- La validación de sesión y conexión con el contexto de autenticación.
Después de cortar ese código y pegarlo en el nuevo hook, es necesario resolver las importaciones: useState, useEffect y useCallback desde React, useNavigate desde react-router-dom, el contexto de sesión desde useSession, los tipos como Order y el servicio getOrders [1:50].
¿Qué debe retornar el hook y cómo se consume en el componente?
El custom hook debe exportar los datos que el componente necesita para renderizar [2:52]. En este caso, el return incluye user, orders, loading y error. En el componente, se importa useOrders y se destructuran estos valores:
javascript
const { user, orders, loading, error } = useOrders();
El resultado es un componente con muchas menos líneas de código [2:30]. Para ti del futuro, o para cualquier persona que tome el proyecto, será más fácil procesar y entender lo que hace cada archivo porque la lógica está segmentada.
¿Cómo verificar que el refactor no rompió nada?
Una vez completada la refactorización, se ejecuta la aplicación con yarn start para confirmar que el flujo sigue funcionando correctamente [3:19]. Pero lo más importante es validar que los tests existentes sigan pasando.
Un truco útil es ejecutar solo los tests de un componente específico: se copia la ruta relativa del archivo y se pasa como argumento a yarn test [3:33]. Como el componente sigue llamando al hook internamente, las pruebas configuradas previamente continúan pasando sin cambios.
Este patrón demuestra que una buena arquitectura no solo facilita el mantenimiento, sino que protege las pruebas existentes ante refactorizaciones. Con el custom hook creado y validado, el siguiente paso natural es escribir tests directamente para useOrders, aislando su lógica del componente visual. ¿Ya aplicas SOLID en tus proyectos? Comparte tu experiencia en los comentarios.
