Foto de Artem Maltsev en Unsplash
Artículo de la serie ¿Que es escalable?, Y que lo es en el desarrollo frontend?.
Hoy en día el término "escalable" se usa en cualquier presentación (de forma totalmente vacía en la mayoría de las ocasiones) para referirse a cómo se caracteriza un producto, sistema y/o aplicación. Pero, ¿realmente sabemos lo que significa? Buscando rápidamente su definición en Google o en algún blog, obtenemos que "incluye componentes chiquitos, customizables, de fácil mantenimiento, independientes entre sí, que sean fáciles de implementar" o también que "la escalabilidad estará dada en su capacidad de crecer y adaptarse a los cambios según la demanda". Son ideas realmente simples, súper universales y que nadie esperaría menos que eso, pero me surgieron las siguientes preguntas: ¿es eso lo que busco al plantear un proyecto escalable? ¿tan solo intentando abstenerme a esas dos definiciones mi proyecto va a ser totalmente escalable? Encuentro que la respuesta es "No", a menos que el proyecto no lo va a tocar nadie más, e ignoro un montón de otros factores importantes a la hora de trabajar en un equipo.
¿A qué quiero llegar con esto? Voy a dar un algunos ejemplos para que quede más claro:
- Una buena documentación, que facilite la comprensión y onboarding del proyecto, no sería parte de ese concepto de escalabilidad. Dando solo un readme con los requisitos y pasos para usar el proyecto de forma local, lo podría probar cualquier otro desarrollador sin tener conocimiento y contexto del mismo.
- Creo un proyecto usando una estructura de carpetas que saqué de un post/video muy reconocido (o la invento yo mismo) y es súper escalable porque "lo usan todos" (amo, y odio con mi más profundo ser ésta frase como fundamento para decidir cosas). Luego de un tiempo, como nadie lo revisó porque es algo que "lo usan todos", encontramos que la mayoría de los desarrolladores no logran entender muchos aspectos de esa estructura, en muchos casos se empieza a cuestionar y solicitar cambios, perdiendo así muchísimo tiempo.
- Los componentes tienen siglas en los nombres, como por ejemplo NBCForm, BDEPopup, MDPage; y cuando ingresan nuevos desarrolladores se necesitará hacerles una introducción y un glosario para que entiendan lo que significan. Esto no es nada escalable, porque esa persona tiene un proceso donde va a tener que memorizar cada una de esas siglas, y en caso de tener un glosario perderá mucho tiempo yendo a buscar sus definiciones. Esto se podría facilitar al nombrar los componentes sin siglas, NewBatchCustomerForm, BillingDetailEditPopup, MovieDetailPage. Los nombres quedarán más largos pero es literal y entendible lo que hacen.
- Ejemplo de una aplicación supuestamente escalable: "El frontend es escalable porque la estructura de las páginas de la aplicación está configurada desde un backoffice que cualquiera de Producto puede usar. Pero Producto nunca lo usa porque en realidad nunca fue una demanda". Entonces hubo una complejización del proyecto muy grande para atacar una demanda que nunca existió.
Que copiemos o creemos un proyecto escalable a nivel código/infraestructura, no significa que va a sobrevivir en un entorno no escalable. Y con esto me quiero referir específicamente a que la escalabilidad del proyecto, la capacidad de adaptarse a los cambios según la demanda, no será dada sólo porque el código que escribamos sea de calidad (obviamente que esto también importa, no lo pongo en duda), sino que el entorno en el cual se desarrolla debe acompañar esa escalabilidad.
Para definir lo que no es escalabilidad, me gustaría seguir dando ejemplos y descripciones, porque a veces lo mejor para definir un concepto tan amplio es muchas veces mostrar lo que no es, pero tampoco es mi objetivo escribir una extensa crítica a lo que el común de las personas perciben por "escalable", pero si desmitificar.
Por lo cual yo definiría la escalabilidad de un frontend como:
- Cuando se pueda adaptar a las demandas y problemáticas específicas que ataca nuestro proyecto.
- Complejizar/abstraer aspectos que no sean relevantes a estas demandas solo resta escalabilidad. Estas abstracciones deberán ser mantenidas con el tiempo, y si no agregan valor se traduce en esfuerzo y tiempo derrochados.
- Debe tener una curva de aprendizaje lo más facil y rapida posible, tener un onboarding de varios meses para cada nuevo desarrollador solo para que entienda la estructura base del proyecto es algo muy común y al mismo tiempo improductivo (no solo para el recién ingresado, sino también para aquellos que lo van a asistir durante el proceso).
Espero que si llegaron hasta aquí, puedan entender un poco más claro ese concepto de escalabilidad, agregando justamente una parte importante en su definición: lo que no es escalable. Entonces, creo que puedo dar por cerrado este tópico, habiendo intentado deconstruir un poco el termino dentro de nuestro rubro, específicamente de Frontend.
Top comments (0)