De Reactivo a Flexible: Cómo Amplié Mis Horizontes como Dev
Command Palette
Search for a command to run...
Comments
Join the discussionNo comments yet. Be the first to comment.
Search for a command to run...
No comments yet. Be the first to comment.
On this page
Hace algunos años tuve una empresa con un amigo mío. Fue una empresa pequeña en la que nos dedicábamos a desarrollo, y una de las experiencias de las que más he aprendido como dev. Cada proyecto me traía desafíos distintos, que a veces incluían hacer saltos de fe con las tecnologías que iba a utilizar.
Me costó mucho ser flexible con esas herramientas (¡siempre quería usar React para todo!). Pero, cuando por fin empecé a serlo, creé un procedimiento que me ayudaba a decidir el stack más inteligentemente. En este post te comparto cómo este proceso me ayudaba a dejar atrás esos saltos de fe y a tomar más decisiones bien informadas.
El primer paso que siempre seguía era investigar cuáles tecnologías tenía disponible para resolver el problema de mi cliente. Si la persona o empresa quieren crear una tienda en línea, necesito encontrar las herramientas que mejor se adapten a ello. ¿Shopify? ¿Medusa? ¿Magento? Hay muchas distintas opciones que pueden usarse.
Para encontrar estas tecnologías normalmente uso diversas plataformas, entre ellas algunas de productos (como Product Hunt), redes sociales (como Twitter y Reddit), información de creadores de contenido (de YouTube, newsletters y blog posts), y recomendaciones que escucho de otros desarrolladores (normalmente de eventos o pláticas informales).
Si no conozco ninguna que pueda servir para mi caso, puedo hacer investigaciones rápidas. Buscar en Google y ver páginas como Stackshare son las formas más comunes en que yo lo hago.
Para cada parte del proyecto hago normalmente una lista de entre 3 y 5 tecnologías que pueden ayudarme a resolver un problema. Entre ellas puedo incluir soluciones enterprise, librerías open source, tecnologías pequeñas, y plataformas no-code.
Puede que este proceso se escuche como algo que consume mucho tiempo, pero intento que tome entre medio día y dos días de trabajo. Y, la verdad, me es muy divertido porque me permite crear una lista de herramientas que quiero aprender o explorar en un futuro. Muchas de ellas quedan descartadas, pero el proceso me ayuda a conocer que hay en el mercado y a acelerar las cosas cuando debo hacer otros proyectos con necesidades similares.
Una vez que ya tengo definidos los requerimientos y algunas tecnologías que quiero explorar más a fondo, creo una tabla comparativa con ciertos criterios que me ayudan a decidir mejor. Cada uno de ellos influye en diferente medida dependiendo del proyecto. Con el tiempo he formado una lista de 9 elementos que utilizo para comparar tecnologías:
Tamaño de comunidad
Soporte del equipo de desarrollo
Roadmaps y madurez de tecnología
Prueba de Concepto (POC)
Expertise con la tecnología
Calidad de documentación
Costo de implementación y hosting
Costo y facilidad de mantenimiento
Seguridad
En esta sección describo cada uno de los puntos más a detalle.
Cuando empiezas a utilizar una tecnología nueva, es casi seguro que tendrás problemas con ella. Una comunidad grande hace más probable que otras personas ya hayan pasado por el mismo problema que tú al usarla, por lo que será más fácil encontrar una buena variedad de fuentes de información en caso de ser necesario.
Normalmente, una comunidad grande significa que la tecnología tendrá mucho material educativo y gente en quienes apoyarte cuando surjan problemas.
No hay nada peor para un desarrollador que buscar una pregunta en Google y que lo único que encuentres es un post de hace varios años con alguien que tuvo la misma duda y ninguna respuesta, por lo que este punto es muy importante.
¿Hay formas de contactar con el equipo de desarrollo de la tecnología? Mientras más informal y rápido sea el medio, mejor. Si tienen un servidor de Discord, foro, Twitter oficial, canal de Slack, o algo parecido, mucho mejor. En mi opinión, una herramienta da mucha más confianza si hay un grupo de expertos con los que puedes contactar cuando aparecen preguntas difíciles.
Aunque este criterio es bastante subjetivo, normalmente me ayuda a determinar si la herramienta está lista para utilizarse en un proyecto de producción. Si no es una tecnología madura, tal vez sea necesario darle algunos meses antes de poder confiar en ella. Por más buena que aparente ser una tecnología, es mejor no ser la primera persona en probarla en un proyecto real si en unos meses puede crear más dificultades que bondades.
Además de esto, un roadmap (plan de trabajo) activo ayuda a saber si la tecnología sigue viva y está en constante evolución. Con esto puedes estar más seguro de que cualquier problema de seguridad, optimización, bugs, u otros detalles, se pueden resolver.
Este paso normalmente requiere un poco de investigación más a fondo que otros, ya que requiere encontrar un proyecto parecido a lo que quieres hacer para tu cliente. Si no existe en documentación oficial, a veces es útil explorar repositorios de código abierto, casos de estudio, y empresas que están utilizando la tecnología.
Si logro encontrar algo similar a lo que necesito, este punto se gana una palomita ✅. Si no, veo si es factible construir el proyecto preguntando a otras personas que tienen más experiencia en la tecnología que yo.
Además de la utilidad general para el proyecto, este paso sirve mucho también para conectar con otros miembros de la comunidad y conocer mejor las cosas que otros devs están haciendo con la herramienta.
¿Tengo experiencia con esta herramienta o con algo similar? Esto es especialmente importante para algunos proyectos donde el cliente quiere que use una tecnología que no conozco. Si es así, voy a incluir en mi planeación algunas horas adicionales para poder capacitarme y sentirme seguro de que lo que estoy creando es de buena calidad.
Algo igual de problemático que no encontrar soluciones a tus preguntas es no encontrar nada de información de tu caso de uso. Hay muchos criterios que puedes utilizar aquí: Información actualizada, fuentes de información bien centralizadas, buena experiencia de uso, entre otras. Todo depende de que tan extensa sea la tecnología.
En mi caso, he trabajado con tecnologías con varios tipos de documentación. Algunas usaban archivos PDF, por ejemplo, con bastante información desactualizada. Otros estaban mal planeados, o tenían funciones de búsqueda rotas. En general, no considerar este paso traía dificultades para que mi equipo y yo encontráramos lo que necesitábamos.
Una buena documentación es muy importante.
Es difícil usar las mismas herramientas con clientes individuales que con empresas medianas; uno no puede aprovecharlas ni costearlas de la misma forma el otro.
Todos los costos aquí son importantes: hospedaje de servidores, de frontend, de bases de datos, etcétera. Tal vez algunos de tus clientes prefieran hospedar su servicio de backend en sus servidores propios, mientras que otros querrán mantener las cosas en la menor escala posible y usar solo servicios gratuitos. Igual que para el resto de los puntos, todo depende del proyecto.
¿Qué tan fácil es que tu cliente puedan dar mantenimiento a su producto una vez acabado? Esto normalmente involucra la facilidad con la que podrán crear contenido o contratar un equipo que pueda dar desarrollo continuo a lo que vas a crear.
Si por algo ya no puedes trabajar con ellos como desarrollador, ¿será difícil encontrar a alguien más que pueda hacerlo? Todo esto es mejor planearlo por adelantado ya que involucra directamente la experiencia que tendrán tus clientes con su plataforma a corto y largo plazo.
Este es un criterio de lo más importante a considerar si tus clientes necesitan guardar datos sensibles. ¿Qué tan importante es que su información se mantenga privada? No es lo mismo trabajar con un restaurante con datos abiertos cuya información incluye solamente datos de sus platillos que trabajar con una escuela que necesita almacenar datos de pago de sus estudiantes.
Si la tecnología que planeas utilizar tiene muchas fallas de seguridad, tal vez es mejor dejarla para un proyecto cuyos datos sean mayormente públicos.
Una vez ponderados los criterios y elegida la tecnología (o tecnologías, en caso de seguir indeciso), me muevo al siguiente paso: aprender cómo usar esta o estas herramientas.
En este paso me enfoco en mejorar mi conocimiento con la tecnología que estoy usando. Aunque normalmente prefiero usar tecnologías que ya domino, este paso es esencial cuando necesito utilizar una tecnología nueva.
Normalmente también paso poco tiempo en este paso, tres días cuando mucho. Además de ayudarme a aprender cosas nuevas, me sirve para conocer más a profundidad la calidad del material educativo que se encuentra a la mano. En este punto empiezo a explorar más a detalle los cursos que existen en distintas plataformas tanto gratuitas (YouTube, blogs, etc.) como de cobro (Udemy y plataformas educativas privadas) y a conectar aun más con desarrolladores de la comunidad.
Si me siento con suficiente tiempo, busco usar las tecnologías que estoy probando para resolver mis dudas específicas. Además, intento aproximar los proyectos a algo similar a lo que haré en el producto final, de modo que pueda reutilizar algunas partes del código que estoy creando.
Gracias a que ya tengo toda esta información, me es más fácil demostrarle a mis clientes que "hice mi tarea" y que puedo darles una decisión más confiada e informada. Usando estos criterios, puedo crear un estimado más detallado de por cuánto tiempo la tecnología les será útil y en cuánto tiempo deben proyectar cambios o mantenimiento a la plataforma que haremos. Además, la información recolectada me ayuda a crear un plan de desarrollo para saber cómo atacaré el proyecto sin importar si es para un producto mínimo viable o algo con más funcionalidad.
Puedo decir que, gracias a este proceso que sigo, algunas de las plataformas que hice en mi época de freelancer han estado en uso y mantenimiento por periodos de entre 3 y 5 años — una de ellas aun activa 6 años después. No todas han sido igual de exitosas, claro. Pero, después de aprender algunas lecciones a la mala, he mejorado el nivel de comunicación que tengo con las personas con quienes trabajo y les he ayudado a tomar decisiones más informadas.
Hay muchos otros factores que juegan un papel importante en el uso de las tecnologías que utilizamos para desarrollar una plataforma. Algunos de ellos, como la calidad de nuestro código y la documentación que creamos, están en nuestro control. Sin embargo, hay otros como la evolución de las tecnologías y las tendencias de la industria que no podemos manejar. En mi opinión, lo mejor que podemos hacer como desarrolladores es tomar una decisión lo más informada posible, y darle la misma opción a las personas con quienes trabajamos.
Ahora dime tú, ¿cómo eliges las tecnologías para tus proyectos?