Hace unos años se consideraba lo que corría en un navegador web como algo “limitado”, si querías desarrollar algo más avanzado tenías que llevarte procesado a servidor o utilizar plugins de tipo Flash / Flex / Silverlight (guardemos un minuto de silencio por todos aquellos a los que nos “vendieron la moto” diciendo que esa era la tecnología definitiva).
Tras la muerte de todos esos plugins, nos encontramos que los usuarios pedían más usabilidad, es decir facilidad de uso, rapidez etc… ¿Eso nos importa? La respuesta es si:
- Si tu página carga lenta los usuarios se van directamente a la competencia.
- Si no puedes hacer un proceso de búsqueda fácil y potente, es más complicado que un cliente encuentre lo que busque, disminuyen tus ventas.
- Si tu proceso de compra no es rápido y fluido, tendrás clientes que se queden en el camino.
- Si tu sitio no es estable o seguro, además de que no vendas te puedes encontrar con un problema considerable.
- Etcetera.
¿Esto a qué nos ha llevado? A darnos cuenta de que el mundo del desarrollo web estaba en pañales, a la proliferación de nuevas versiones o nuevos lenguajes, y a la aparición de multitud de frameworks y librerías, por nombrar algunas: backbone, ember, knockout, angular 1, angular 2, reactjs, redux, vue, next, cyclejs…
En Lemoncode complementamos nuestras actividades de formación con consultoría y coaching, una de las conversaciones que solemos tener con clientes cuando arrancamos un proyecto de esta índole es la siguiente:
[Cliente] Hace diez años elegimos stack de tecnología para desarrollar web, se nos ha quedado obsoleta… necesitamos hacer una nueva elección, ¿Cuál me da garantías de que será válida para los próximos diez años?
[Lemoncode] Ninguna.
[Cliente] ¿¡¿¡ Cóóómooo ¡?!? Esto no es serio, sé que a vosotros os gusta mucho jugar con todo lo nuevo, pero nosotros no estamos para eso tenemos un producto que mantener, no podemos hacer una apuesta de migración a algo que no vaya a tener continuidad, entonces ¿Nos quedamos con nuestra tecnología antigua y seguimos desarrollando?
[Lemoncode] Tampoco podéis, vuestra tecnología se ha quedado obsoleta, y no es capaz de soportar lo que un usuario espera de ella, se irían a la de la competencia.
[Cliente] ¿Entonces qué hacemos?
Seguro que a más de uno esta conversación os resulta familiar y la habéis tenido con vuestro jefe o cliente, … es más igual hasta habéis hecho apuesta con Angular 1 y os habéis tenido que tragar vuestras palabras cuando visteis que Angular 2 se parecía a la versión anterior como un huevo a una castaña (a nosotros nos pasó en su día con Silverlight.. esto es el fuuuutuuuuroo.. ¡Anda que lo han descontinuado!).
No existe una solución óptima para este problema, la que nosotros aconsejamos es la siguiente:
- Separación de concerns: tener claramente separado un proyecto que sirve datos (tu api) del proyecto de front end (que sirve HTML / JS y se alimenta de la api de datos).
- Apoyarte en una versión potente de javascript (ES6) o Typescript, y realizar transpilaciones a ES5 para no perder compatibilidad con navegadores antiguos (esperamos que un día no haga falta esto).
- Ver que partes de tu aplicación no tienen que depender del super framework que lo hace todo por ejemplo:
- Para las validaciones de formularios podéis utilizar aproximaciones puras de javascript y apoyaros en librerías externas especializadas. Así el día de mañana si cambias de por ejemplo Angular a React ó Vue ese código lo reaprovechas.
- Para el acceso a datos, puede plantearte utilizar “fetch” de ES6 o alguna librería (e.g. Axios).
- No pensar en migrar un dinosaurio de 10 años de desarrollo en modo big bang, fragmentarlo en aplicaciones independientes e ir haciendo una migraciones parciales (aprendiendo de los errores y evolucionándola).
- Desarrollar primero proyectos de baja prioridad con uno u otro framework (o dejarte aconsejar por un experto si este tiene experiencia real con ellos), y finalmente elegir uno para ser usado en los próximos dos años (fijar rumbo).
- No dejar de lado el pulso de la tecnología, ir viendo cómo evoluciona y evaluar cuando es necesario cambiar.
- A la hora de reemplazar el framework / librerías que usemos: aplicarlo primero a desarrollos pequeños de baja prioridad, ver como se porta y como escalaría, y de ahí, promocionarlo a estándar de desarrollo global si vemos que da lo que necesitamos.
- Los desarrollos que ya hayas migrado y se hayan quedado antiguos: evaluar su importancia y criticidad y plantear una migración a la nueva tecnología (imagínate que hace dos años implementaste una parte de la aplicación con Angular 1, si está ha resultado ser un éxito y es parte de nuestro core del negocio plantear una migración al nuevo framework con el que estemos desarrollando).
Como una persona me dijo un día “Esto es como cuidar jardines, nunca te aburres, cuando has terminado de arreglarlo todo, tienes que volver al principio para empezar de nuevo”.
Ventajas de este método:
- Las migraciones no son tan dolorosas y aprendes de los errores (es más fácil migrar un módulo que no la aplicación completa).
- No arrastras una decisión equivocada para todo el proyecto.
- Tu equipo de desarrolladores no se ancla a un producto / tecnología, es más difícil que se queden obsoletos y están más preparado para el cambio.
- Te puedes centrar en que las partes críticas de tu producto estén a la última.
- Al tenerlo ya troceado, es más fácil poder vender submodulos de tu producto como productos independientes.
Desventajas:
- Tu producto va a estar compuesto por varias tecnologías, va a existir fragmentación.
- Tienes que plantear que la vida media de una subaplicación va a ser de entre 2 y 4 años.
Tienes que invertir en I+D: parte del tiempo de ciertos desarrolladores tiene que ir a que estén al día y evalúen lo que hay en el mercado.
¿Y tú qué opinas?