Una pequeña charla conmigo mismo
¿Crear herramientas propias para el desarrollo? Gastón recorrió este camino y nos comparte su experiencia.
Día a día estamos frente a una búsqueda por mejorar nuestra calidad de código, entregar un buen producto y llenarnos de orgullo con lo que desarrollamos. Invertimos tiempo para aprender nuevas tecnologías, herramientas y metodologías de trabajo para ser mejores, pero también tenemos que invertir en nuestras herramientas del día a día. Nuestro ambiente de programación favorito, no sólo está ahí para escribir, correr los tests y ejecutar el código, es nuestro mejor aliado para tener que olvidarnos de las tareas tediosas y rutinarias y poder darnos feedback rápidamente.
Más de una vez, sentí la necesidad de agregar una funcionalidad a mi IDE. A veces, buceando en la profundidad, encontraba un plugin o una herramienta que me servía para esa ocasión, pero no siempre es así.
Entonces, se presentó la oportunidad perfecta: tenía que realizar el trabajo final (llamado Trabajo de inserción profesional), para recibirme como técnico en la Universidad Nacional de Quilmes. El tema, en esencia, era libre así que junto con mi compañero decidimos hacer algo distinto de lo usual. Para experimentar, queríamos desarrollar una herramienta para desarrolladores.
Nuestra idea fue desarrollar COOP, un linter para CuisUniversity, que es una distribución de Smalltalk diseñada y sponsoreada por gente de 10Pines para aprender programación orientada a objetos. Nuestra principal motivación en ese momento era tener un algo, que ayude a los estudiantes de Programación con Objetos 1 (una materia de la Tecnicatura de la que egresé) mientras desarrollan y en su camino de aprendizaje contínuo.
El código es más que texto
Una vez que empezamos a desarrollarlo, además de las dificultades derivadas de nunca haber hecho algo así, logramos confirmar el porqué decidimos hacerlo en un entorno vivo como Smalltalk, poder disponer del código vivo e ir agregando reglas o modificaciones en vivo. Nos dimos cuenta del valor que esto realmente representa. La primera vez que logramos recolectar información de un método de una clase, y entender bien cuál era la regla que deseábamos aplicar, sentimos que habíamos hecho magia. La realidad es que no, solamente habíamos perdido el miedo. De hecho, antes de lograrlo, habíamos roto muchas veces la imagen de Smalltalk, pero por cada ruptura sabíamos que nos acercábamos más a nuestra meta. Quizás la parte que más abrió nuestra cabeza fue la de utilizar la misma herramienta para programar la herramienta: Nos guiaba en vivo y en directo sobre dónde había que codificar, mientras añadíamos la nueva inspección.
Por ejemplo, el hecho de agregar una nueva regla implicaba que recorrer el AST (abstract syntax tree) que representaba el método del mensaje que se estaba inspeccionando. En ese momento , si no habíamos desarrollado algún caso borde de la estructura del método, COOP, al inspeccionar, levantaba una excepción. Sabíamos, entonces, por dónde nos estaba diciendo que “no me completaste”.
Coop en acción
Aquí podemos ver a COOP mostrando una regla que falla (tests que no tienen aserción):
En este video vemos una regla (preferencia de isEmpty
sobre size == 0
), que se puede corregir manual o automáticamente, más una regla que detecta condicionales innecesarios:
No se trata de llegar hasta el final, se trata de cambiar en el camino.
El camino que recorrí fue particularmente enriquecedor en muchos sentidos: no solamente logré recibirme, sino que encontré vencer y romper esos miedos y dudas que sentía al crear una herramienta para personas que desarrollan, al poder acercarme un poco más a la comunidad que siempre está para acompañar y guiar cuando el terreno que se está pisando es difuso.
Recomiendo muchísimo adentrarse en este mundo y, más que nada, jugar y experimentar. Siempre se puede “romper todo”, pero la experiencia de ver tu programa ayudándote a desarrollarse a sí mísmo es increíblemente mágica y divertida.