El ciclo de desarrollo

Los dos ritmos

La tercera fila es la que duele, y explica una decisión de diseño que aparece sola: la gente acaba poniendo en el frontend lógica que debería estar en el core, simplemente porque iterar ahí es más rápido. Merece resistirlo — y merece atacar la causa.

Acortar el lado lento

La segunda es la que más rinde a largo plazo y encaja con lo que las fases anteriores han ido separando: la capa de datos del nivel 42.4, la de secretos del 37.5 y la de red del 48.5 son candidatas naturales a vivir en paquetes propios — que además se prueban solos, que era la otra razón para separarlas.

Conservar el estado entre recargas

Para el lado rápido, lo que hace que iterar sea agradable:

• Actualización en caliente de módulos, si tu marco la soporta: cambia el componente y el estado sobrevive.
• Y si no, un modo de desarrollo que restaure el punto donde estabas: iniciar sesión automáticamente con credenciales de prueba, abrir el último proyecto, ir a la última pantalla.

Lo segundo suena a artesanía y vale mucho más de lo que cuesta: media hora de código que solo existe en desarrollo y que ahorra veinte pasos manuales en cada reinicio del core.

#[cfg(debug_assertions)]fn restaurar_sesion_de_desarrollo(app: &AppHandle) { /* … */ }

Y con la condición de compilación, para que no llegue a producción — que es exactamente el tipo de código que se cuela si no se marca.

Dónde iterar

Una decisión práctica que sale de todo esto: cuando estés explorando algo, hazlo primero donde iterar sea barato, y muévelo después a donde corresponde.

• Explorar la forma de una interfaz: en el frontend, obviamente.
• Explorar un algoritmo o una consulta: en una prueba del core, no en la aplicación entera. Es la ventaja del nivel 42.4 — un módulo que se prueba solo itera en segundos.
• Y explorar la interacción entre los dos: no hay atajo, y es donde las cinco formas de acortar la compilación se pagan.