La Guía del Desarrollador Perezoso: ¿Cómo Automatizar las Actualizaciones de Código?

Hola a todos y les envío un gran, gran, gran saludo desde Croacia. Mi nombre es Ante y hoy voy a hablarles sobre temas muy interesantes que son las automatizaciones de código y cómo las implementamos en Neo4j. Espero que disfruten de mi sesión, así que comencemos. Hola, soy Ante y tengo 28 años. Soy ingeniero de software senior que trabaja en Neo4j desde hace casi 6 años y me enfoco en la infraestructura. También soy un orador frecuente en meetups y tengo muchos intereses como React, Webpack, Construcción de Aplicaciones, Optimización de Aplicaciones, Rendimiento, Arquitectura Web, Automatización y Experiencia. Y saben, todos los que me conocen les dirían que soy un gran aficionado a la fotografía y amo la fotografía, soy un fotógrafo feliz. Así que si están interesados, no duden en visitar mi blog de fotografía en Instagram, pero comencemos con una pregunta, ¿cómo manejan las tareas repetitivas en el trabajo? Esto es algo que me gustaría que respondieran en la encuesta, así que veamos, tal vez estamos haciendo copiar, pegar y luego repetir, repetir y repetir lo mismo, o por ejemplo, contamos 20 proyectos y luego cambiamos lo mismo en todos ellos. Bueno, tenemos muchas tareas repetitivas y esto puede llevarnos mucho tiempo, especialmente cuando tenemos 50 o más proyectos, y podemos ver como en esta línea azul que podemos hacer esto manualmente, ya saben, y también podemos ver este rojo que es en realidad lo que quiero explorar en esta sesión, ya que también está relacionado con el concepto de automatización, que es extremadamente importante, y me gustaría comenzar con una cita y eso es que siempre elegiré a una persona perezosa para hacer un trabajo difícil porque una persona perezosa encontrará una manera fácil de hacerlo y veamos cómo esto se aplica en realidad. Lo primero es lo primero, no está relacionado con que debamos ser perezosos para aprender. No, la programación es una habilidad que lleva horas y horas perfeccionar y definitivamente debemos trabajar duro para convertirnos en mejores desarrolladores y ampliar nuestros conocimientos. Y entonces, ¿de qué demonios estoy hablando? Bueno, necesitamos ser capaces de elegir nuestras batallas sabiamente porque trabajar duro es tan importante como trabajar de manera inteligente. Y en el desarrollo, las misiones son clave para lograr todo esto y vamos a comprobarlo con algunos ejemplos. Pero también necesitas mencionar el pensamiento. Obviamente, es la parte más difícil del desarrollo, ¿verdad? Especialmente cuando tienes que nombrarlas. Pero el pensamiento es en realidad una herramienta muy poderosa para las misiones porque nos ayuda a producir ideas y soluciones y también nos ayuda a buscar activamente desafíos y mejoras. ¡Pero espera! Tenemos que tener cuidado de no pensar demasiado, porque nuestro tiempo es valioso y no deberíamos perder demasiado tiempo en complicaciones, ya que dificultará el soporte y la actualización del código en el futuro. Tal vez podamos tener buenas intenciones, pero nuestro código puede ser demasiado complejo de entender. Y esto es algo que comprobaremos en los ejemplos de código. Pueden ver el código QR y el enlace del repositorio aquí para que puedan seguir conmigo o pueden revisar el repositorio más tarde. Bueno, entonces vamos a ello. Lo que quiero mostrarles es este archivo package.json. Este es mi proyecto para el proyecto ficticio o ejemplo uno para las ecuaciones médicas y quiero llamar su atención sobre estas dependencias. Lo que tengo en las dependencias es una herramienta CLI llamada oclf. Ahora es su preferencia lo que elijan. Yo simplemente elegí oclf porque es fácil de integrar y configura muchas cosas de inmediato. Así que me ayuda y ofrece muchas posibilidades e integraciones. Pero saben que tienen más opciones como commander o yars y, por supuesto, también tienen oclf si lo desean. Pero lo que también pueden ver son algunas otras dependencias. Tienen algunas menores, tal vez menos conocidas, como edit json file o replace-in file, que pueden buscar y usar según su necesidad.

Y tienes más herramientas populares como stemware que se utiliza para el versionado semántico. Puede ayudarte a verificar qué versión tienes y si coincide con la versión que necesitas y yada yada yada. Luego tenemos shelljs, que es una biblioteca similar a Unix que te ofrece la opción de ejecutar comandos Unix en cualquier entorno, como Windows, macOS, Linux u otros. Y algunos de ustedes seguramente están familiarizados con uh, simplemente usan ships para hacer actualizaciones y, por supuesto, también se puede usar. Pero me gustaría hablar de dos ejemplos que voy a mostrarles. El primero es el comando eslint-update, donde simplemente vamos a verificar si tenemos eslint link fix, que también pueden ver en los paquetes a la derecha, y si verifican los scripts aquí, verán que no lo tenemos. Así que agregaremos link fix para la actualización automática. El segundo comando es la actualización de dependencias, donde simplemente verificaremos si tenemos react 16 y si lo tenemos, simplemente actualizaremos la versión a react 17. Ok, vamos a verificar, así que tengo eslint comandos de actualización con cuatro partes, la primera es el filtro donde generalmente en gi I usamos big packet api para descargar el archivo package json para que podamos hacer algunas verificaciones rápidas. Como pueden ver aquí en el filtro, usamos el archivo package.json para cada paquete.json descargado para el proyecto para verificar si tenemos eslint, por supuesto, tenemos eslint, así que si ejecuto el comando que tienen aquí en el ejemplo, que también puede ayudarte verán que obtendré un resultado de azure, lo que significa que mi migración se ejecutará. Así que ese es el primer paso hecho. El segundo paso es clonar el proyecto. Cada proyecto para el cual ejecutamos el filtro y devuelve verdadero se clonará y luego, antes de ejecutar la migración dentro de indexts primero verifico estas migraciones y este es un filtro ampliado donde gracias a package package, ya saben, gracias a todo el proyecto clonado, puedo verificar absolutamente cualquier cosa que quiera. No sé, por razones de simplicidad, estoy verificando package.json aquí para simplemente ver si tengo el comando linpicks y como no tengo el comando linpicks, aquí pueden ver que devolverá verdadero. Entonces, si ejecuto mi comando de migración, devolverá verdadero y luego podré ejecutar la migración principal o al menos se ejecutará en el trabajo de TI. Entonces, voy a index.js y puedo ver mi comando de migración principal. Pero está escrito aquí como pueden ver aquí hay dependencias adicionales que generalmente se instalan. Aquí es donde principalmente las usarás. Entonces, dentro de tu trabajo de migración. Y aquí estoy usando el archivo JSON. Como pueden ver aquí en el comando de migración donde primero obtengo mi ruta al proyecto, luego he agregado un archivo JSON y dentro de mi paso de lintfix donde simplemente también verifico si ya tengo el comando lintfix. Y si no tengo el comando lintfix, entonces lo agrego a un archivo JSON y también se guardará automáticamente. Y nuevamente, vamos a verificar el ejemplo de código aquí. Así que lo copiaré y lo ejecutaré el comando run eslintupgrade. Y verán aquí que ahora lintfix ha aparecido y tengo cambios en mi proyecto de GitHub. Así que, voilà, sé que está funcionando. El segundo paso que quiero mostrarles es la actualización de dependencias. Pero antes de pasar a la actualización de dependencias, quiero mencionar brevemente las opciones de migración que no las obtendré, pero puedes usarlas para obtener las opciones e información que necesites para la ejecución automática del trabajo o incluso para solicitudes de extracción y eso. Entonces aquí puedes pasar, puedes recuperar, puedes calcular cualquier información que necesites para tu entorno de TI. Pero lo que me gustaría hacer es pasar a la actualización de dependencias.

Y lo que tengo dentro de la actualización de dependencias, como dije, es verificar si tengo react-16, lo cual, si miras los paquetes y te lo muestro desde el proyecto de prueba de ejemplo aquí, puedes ver que tengo la versión 16 de react-dom, lo que significa que soy elegible para la actualización. Ahora, no te mostraré los cuatro pasos, pero puedes ver aquí que estoy actualizando react-dom. Tengo algunos comandos exec y npm install. Y voy a iniciar el proyecto. Esto significa que estoy ejecutando comandos similares a Unix. Y lo estoy haciendo, como puedes ver en la parte superior, tengo shelljs donde estoy ejecutando algunos comandos. Entonces, como tengo shelljs aquí, tenemos import xtd from shelljs, tengo los comandos. Y si los ejecuto, algo sucederá. Y como verás, podrás ver cómo reacciona y se actualiza react-dom paso a paso. Porque ve react y luego react-dom, y luego todo lo demás. Y terminará, se envolverá y se ejecutará con éxito. Pero esto no es algo por lo que esperaré, porque quiero mostrarte un último ejemplo. Y ese es este archivo. Sabes que cuando escribimos un proyecto, tenemos ESLint y tenemos VDR. Y tenemos esos dos. Esos son para el formateo de código y para corregir posibles errores básicamente para garantizar la calidad del código. Pero esto también se puede considerar como automatización. También podemos considerarlo como pereza. ¿Por qué? Porque no formatearemos esto automáticamente. Puedo configurar mi IDE, por ejemplo, para guardar esto y luego formatearlo, que es lo que voy a hacer. Y cuando lo guarde, ok, no funciona. Pero simplemente puedo ejecutar los comandos de código aquí y puedo ver que a medida que arreglo algo, se formatea automáticamente y se hace exactamente como quiero que se vea. Entonces, también es un muy buen ejemplo de pereza. Y también llamémoslo automation. Puedes explorar este proyecto por ti mismo, si quieres, y es extremadamente útil. Y también agregaré más ejemplos. Así que te recomiendo encarecidamente que lo revises. Ok. Me gustaría volver a la presentación.

Para evitar ese problema, tenemos nuestra biblioteca interna de migración con trabajos y ejecuciones automáticas para la integración continua y Jenkins. Entonces, ¿qué paso damos? Resolvemos esto. Filtramos donde verificamos qué proyectos son elegibles para actualizaciones según la API de Bitbucket. Eliminamos proyectos innecesarios y luego podemos continuar. Según eso o el alcance o los resultados que nos quedan, simplemente los clonamos. Después de haberlos clonado, antes de realizar las acciones, podemos hacer la verificación adicional para eliminar más proyectos. Pero, por supuesto, después de verificar, no sé, esta migración, pasamos a index o al comando de migración donde realizamos las acciones definidas. Luego tenemos nuestros cambios de código que necesitamos confirmar. Luego los enviamos y también creamos una solicitud de extracción para que los equipos puedan revisarla. Y tenemos más ejemplos aquí.

Un ejemplo es muy familiar para todos ustedes y es la integración continua y el despliegue continuo donde también podemos usar muchas herramientas como Jenkins o Docker o Kubernetes con incluso algunas herramientas integradas como webpack, rollup, no sé, parcel y mucho más. Y tenemos un buen caso de uso del sitio InfoWeb y eso es la localización continua. Lo que queremos es que los equipos no se preocupen por localizar el producto, y queremos lograr la integración o localización automática dentro de un proyecto y queremos ofrecer múltiples idiomas a nuestros clientes. Entonces tenemos alrededor de 50 proyectos web que requieren actualizaciones y localización. Entonces, en lugar de actualizar todo manualmente, usamos automatización.

Y el caso de uso que tenemos aquí es que el UXWriter cambiará el texto. Guardarán los cambios en un sistema de gestión de letras basado en la nube. Y luego ejecutaremos periódicamente el trabajo de automatización en todos los proyectos web que reemplazarán nuestro texto con el nuevo que agregó el UXWriter. Y luego generará una solicitud de extracción para que los equipos la revisen. Y tenemos otro ejemplo, que tal vez no estemos familiarizados pero es extremadamente útil y está relacionado con el texto de desarrollo, que es muy importante, pero es difícil de mantener debido a tareas complejas, como la integración y las pruebas de extremo a extremo que son especialmente muy inviables de mantener cuando se está bajo el plazo. Pero tenemos pruebas automatizadas y autogeneradas para motivar las pruebas donde puedes decirle al programa, oye, así es como se supone que debe comportarse y funcionar la aplicación. Así que por favor genera la prueba y también registra los casos límite. Y luego, gracias a la Máquina de Estados y los Diagramas de Estados, tendremos las pruebas generadas para todos los casos de uso. Y aquí podemos ver un ejemplo simple de pasear a un perro, y podemos ver cómo pasamos de un estado a otro.

Y podemos ver cómo pasas de un chapoteo a una caminata. Solo necesitas salir de casa. Y esto es realmente bueno y útil, y es un tema muy amplio y bueno. Y te recomiendo que revises los enlaces de arriba, que son documentación y visualización. Y tenemos una persona increíble llamada David Kershad, quien es el autor de S-State. Realmente estoy haciendo mucho con eso, y definitivamente te recomiendo que revises sus sesiones. Especialmente en el código QR a continuación. Y echa un vistazo al gráfico. Debo decirte que no se trata de hacer la menor cantidad de trabajo, porque queremos contribuir tanto como sea posible, pero también usar nuestro tiempo con el mayor valor e impacto posible. Y estamos aquí para ayudarnos mutuamente. Entonces esto no es una competencia. Todos deberíamos ganar. Entonces si podemos automatizar algo que pueda ayudar a otros, entonces simplemente hazlo. Especialmente si puede ayudarte a ser más productivo y permitirte trabajar en paralelo en otra cosa.

Y algunos de los factores importantes para la automatización son el tiempo, especialmente cuánto se tarda en realizar tareas repetitivas, la energía, porque podemos gastar mucho en tareas repetitivas, y puede ser agotador mentalmente. Luego, hacer las mismas tareas repetitivas puede ser realmente molesto y frustrante y afectar nuestra productividad. Luego, si cambiamos a una tarea diferente, podemos perder el enfoque y tardar más tiempo en retomarlo. Y también, situaciones como esta son buenas cuando ya has cumplido con tareas repetitivas, por lo que una buena curva de aprendizaje con la que puedes crecer es aprender automatización, aprender algo nuevo y pensar fuera de la caja. Entonces, esto es algo bueno para la conclusión porque siempre debemos buscar los patrones y verificar si necesitamos automatizar algo. Y el tiempo es valioso, y debemos enfocarnos en la productividad y los cambios que pueden tener un impacto con el cliente. Y debemos mantener nuestro código simple y más fácil de actualizar más adelante. Si quieres aprender más sobre esto, puedes revisar mi pequeña página que tiene un resumen, materiales y alguna información adicional. Siéntete libre de revisarla. Espero que encuentres útil esta sesión y que puedas aprender algo nuevo. Puedes contactarme por correo electrónico y gracias. Y espero escuchar tus preguntas en la sesión de preguntas y respuestas en unos momentos. Gracias y adiós. ¿Estás sorprendido? No, no lo estoy. Así es como las personas, quiero recordar esto, cómo las personas manejan tareas repetitivas en el trabajo, ¿verdad? Adelante, Ante. Bueno, ya sabes, generalmente es algo frecuente

Absolutamente. ¿Y qué bibliotecas o herramientas recomiendas para la automatización? ¿Cuáles son tus favoritas? Bueno, hoy en día tenemos muchas posibilidades. Sabes, definitivamente la herramienta número uno que recomiendo si haces algunos de los metascripts es algo que todos saben que está bien hecho. Porque tenemos la versión semántica en el proyecto de Node.js. Lo que obtenemos con ella es que puedes verificar la versión. Podemos ver si realmente cumplimos alguna condición. Y es una herramienta bastante poderosa. Especialmente cuando necesitas verificar, digamos, paquetes, como hice en el ejemplo. Luego también podemos tener comandos Unix. Porque a veces necesitas ejecutar npm install o uninstall algo. O incluso acceder a algún archivo. Eso es algo cuando si tienes, digamos, una computadora con Windows y estás ejecutando tu trabajo de CI en, no sé, Ubuntu o máquina Linux, entonces puedes tener problemas con inconsistencias. Si puedes usar algo como unificar el comando Unix, que es precisamente shelljs que mencioné, es bastante bueno. Y también tengo que mencionar especialmente algo que no mencioné mucho durante la sesión, y eso es Cisco ship. Y ejecutar el modo de código e incluso escribir el tuyo propio. Lo cual es algo que definitivamente puede ser extremadamente útil. Correcto. Entonces, lo que estás diciendo es que es bueno ser un desarrollador perezoso y automatizar tanto como sea posible. ¿Verdad? Porque tenemos muchas oportunidades y tenemos muchas herramientas que podrían ayudarnos o pueden ayudarnos a hacer estos trabajos repetitivos. Sí. Y no manualmente. ¿Verdad? Bueno, sí. Sabes, no formateamos el código manualmente o algo así. Ya tenemos cierta pereza interna y eso se manifiesta en forma de estas herramientas. Y si podemos automatizar alguna acción, lo cual también, porque las máquinas realmente definen lo que queremos y a medida que definimos lo que queremos lograr, podemos obtener eso automáticamente. Podemos centrarnos en realizar alguna acción que realmente pueda contribuir más porque si eliminamos la necesidad de imprimir manualmente ese código, podemos tener más tiempo para entregar otras características para lograr más. Sí, eso es más importante, ¿verdad? Podemos centrarnos en el código, podemos centrarnos en una nueva característica, en lugar de centrarnos en tareas no diferenciadas. Sí, es cierto. Y ¿cómo deciden los desarrolladores, equipos o líderes técnicos cuándo es el momento adecuado para automatizar o construir un pipeline de automatización para una tarea?