El reparto entre las dos mitades
La decisión que más determina cómo envejece un proyecto: qué vive en Rust y qué en el frontend, con los cuatro errores de reparto que se pagan tarde.
El criterio
Y la regla de una línea: en el core lo que sería igual si la interfaz fuera otra; en el frontend lo que cambiaría.
El reparto típico
De una aplicación sana, en proporciones:
- El core es más grande de lo que la gente espera: la mayoría del código propio.
- El frontend es fino: pantallas, componentes, interacción y presentación.
- Y los comandos son pocos y de dominio. Nivel 14.4: si hay cincuenta comandos primitivos, algo se repartió mal.
Y una señal buena: si el frontend se pudiera reescribir con otro marco en dos semanas, el reparto está bien. Nivel 53.1.
Los cuatro errores
El primero es el más común y el más caro, porque no se ve hasta que hace falta probar, portar o auditar — y entonces está repartido por todas partes.
Corregir un reparto desequilibrado
Y se puede, aunque duela:
- Empieza por lo que más pese: la lógica de negocio que esté arriba y que se pueda mover entera.
- Mueve con pruebas: escribe la prueba de la lógica en el core primero, y luego mueve.
- Y no lo hagas todo de golpe: un reparto se corrige por partes, y cada parte movida ya paga.
Y la señal de progreso: cada vez que muevas algo, el frontend debería quedar más fino y las pruebas del core cubrir más.