Infusion es una herramienta de código abierto que se utiliza para generar documentación en sus archivos de código. Utiliza el modelo OpenAI gpt-4 para escribir comentarios. Era mi proyecto y lo escribí en Python.

Enlace de GitHub:
https://github.com/SychAndrii/infusion

explainer.js es una herramienta de código abierto que se utiliza para explicar fragmentos de código en sus archivos de código. Utiliza modelos de Groq para escribir comentarios. Fue un proyecto de mi compañero de equipo @aamfahim y lo escribió en Node.JS

Enlace de GitHub:
https://github.com/aamfahim/explainer.js

Actualmente estoy inscrito en un curso de código abierto en Seneca Polytechnic, donde se nos asignó la tarea de formar equipo con otra persona, revisar el código de cada uno y dar algunas sugerencias para mejorar usando los problemas de GitHub. Voy a describir este proceso.

Modo de comunicación

La mayoría de los problemas generados para ambos repositorios se realizaron mediante comunicación sincrónica a través de una llamada de Discord. Después de eso, hablamos de forma asincrónica usando mensajes de Discord, ya que para mí era difícil agilizar la configuración de mi proyecto usando scripts bash, y llamar a mi compañero de equipo cada vez que necesitaba probar si funciona en su máquina parecía innecesario. Probar usando contenedores Docker y el subsistema WSL Linux en mi máquina no fue lo mismo que probarlos en el sistema de Al, y destacó errores importantes.

Experiencia de revisar el código de alguien.

No experimenté nada inusual al revisar el código de mi compañero de equipo, ya que tengo mucha experiencia con el desarrollo de Node.JS. Sin embargo, me gustaba crear problemas y luego sugerir inmediatamente soluciones. Un problema que tuvimos es que no pudimos encontrar una manera de permitirme poner etiquetas en los problemas que creé, solo Al podía hacerlo, lo cual era molesto.

Experiencia de alguien revisando mi código

Al sugirió mucho margen de mejora, particularmente con la instalación de mi herramienta CLI. Cuando bifurcó mi repositorio por primera vez, era un requisito que los usuarios finales instalaran una versión particular de Python manualmente, lo cual definitivamente es una tarea frustrante. Además, destacó otras posibles mejoras para el uso conveniente de una herramienta, como introducir el archivo .env para que no tenga que ingresar su clave API cada vez que inicie la herramienta. Me gusta recibir comentarios de otras personas sobre mi código porque me permite crecer como desarrollador y definitivamente amplía mi visión del ciclo de vida del desarrollo.

Problemas durante la revisión y las pruebas

La mayoría de los problemas que tuvimos fueron con mi herramienta, porque el programa CLI de Al fue escrito en Node.JS y ambos tenemos mucha experiencia con él. Por el contrario, a ninguno de nosotros nos gusta el ecosistema Python, por lo que tuvimos muchos problemas para interactuar con él. Al probar el repositorio de Al, encontré que los documentos escritos en su README eran engañosos o confusos de entender, especialmente las opciones de modelo y clave de API. Tuvimos que pasar por el proceso de pruebas y errores para descubrir qué claves y modelos API acepta su herramienta. Cuando llegó el momento de probar mi repositorio, la versión de Python en el sistema de Al estaba muy desactualizada (2.7), por lo que tuvo que instalar la 3.10.6 (versión requerida para usar mi herramienta) manualmente. Sin embargo, ni siquiera entonces terminaron los problemas. Aunque lo instaló, el entorno virtual que crea mi herramienta todavía no lo reconoce con pipenv. Después de eso, también nos frustraba ingresar la clave API requerida para el uso de mi herramienta cada vez que la iniciamos. Finalmente, los documentos README no ayudaron con la instalación. Intentamos seguirlos, pero seguíamos recibiendo errores relacionados con algunos scripts que no se reconocían en la RUTA. Fue entonces cuando decidí que necesitábamos algún tipo de herramienta de automatización que hiciera toda la instalación por usted. Una idea que tuve fue dockerizar la aplicación, pero luego tendría que asignar de alguna manera los volúmenes de Docker al directorio de salida y los archivos de entrada especificados para mi herramienta, y eso complicaría todo dos veces. Por lo tanto, recordé que muchos administradores de paquetes son en realidad herramientas de línea de comandos, y si los instalas clonando un repositorio de GitHub, entonces debes configurarlos ejecutando algún tipo de script de configuración de bash. Entonces esa fue la idea que decidí implementar. Finalmente, ninguno de los dos pudimos encontrar una manera de asignar etiquetas como error o mejora a los problemas que presentamos.

Problemas que presenté

https://github.com/aamfahim/explainer.js/issues/13
https://github.com/aamfahim/explainer.js/issues/12
https://github.com/aamfahim/explainer.js/issues/11
https://github.com/aamfahim/explainer.js/issues/10
https://github.com/aamfahim/explainer.js/issues/9

Para resumir los problemas que encontré, en su mayoría cubrían casos en los que las opciones escritas en el archivo README de este proyecto en realidad no funcionaban o la forma en que funcionaban se describía de manera engañosa.

Problemas que se presentaron en mi repositorio

https://github.com/SychAndrii/infusion/issues/11
https://github.com/SychAndrii/infusion/issues/10
https://github.com/SychAndrii/infusion/issues/9
https://github.com/SychAndrii/infusion/issues/8

Para resumir los problemas que se encontraron en mi repositorio, en su mayoría estaban relacionados con la conveniencia de uso de mi herramienta. Además, hubo un error cuando proporcionaste un archivo con código fuente sintácticamente correcto a mi herramienta, y lo identificó como un archivo que no contiene código fuente válido.

Problemas que logré solucionar

Solucioné todos mis problemas. Todos ellos tardaron menos de 30 minutos en solucionarse, pero hubo un problema que me llevó entre 2 y 3 horas solucionar:
https://github.com/SychAndrii/infusion/issues/8

Me parece extraño ya que la mejora del archivo README debería ser fácil de lograr, pero la primera sugerencia de Al me requirió rehacer completamente el proceso de instalación de mi herramienta, lo que me obligó a introducir 2 scripts para la instalación: uno para bash y uno para Powershell. El problema que no pude resolver la mayor parte del tiempo fue que, aunque estos scripts de configuración instalaron correctamente la versión necesaria de Python, esta versión de Python no se transmitió al entorno virtual, al que debes ingresar antes de usar mi herramienta. Al final lo arreglé.

lo que aprendí

Definitivamente he mejorado mis habilidades README. La forma en que proporcioné el uso de ejemplo fue muy confusa para el usuario final. Además, finalmente usé los lenguajes bash y powershell para hacer algo por mí mismo, no para una tarea escolar, no porque fuera un requisito, sino porque quería simplificar el proceso de interacción con mi herramienta. Finalmente, decidí enfrentarme a un lenguaje que no soporto en absoluto: Python. Definitivamente no fue divertido trabajar con él, pero creo que es esencial poder usarlo si quieres encontrar un trabajo hoy, especialmente con la tendencia de la IA.