Infusion é uma ferramenta de código aberto usada para geração de documentação em seus arquivos de código. Ele usa o modelo OpenAI gpt-4 para escrever comentários. Foi meu projeto e escrevi em Python.

Link do GitHub:
https://github.com/SychAndrii/infusion

explainer.js é uma ferramenta de código aberto usada para explicar trechos de código em seus arquivos de código. Ele usa modelos Groq para escrever comentários. Foi um projeto do meu colega de equipe @aamfahim e ele escreveu em Node.JS

Link do GitHub:
https://github.com/aamfahim/explainer.js

Atualmente estou matriculado em um curso de código aberto na Seneca Polytechnic, onde fomos incumbidos de nos unir a outra pessoa e revisar o código um do outro e dar algumas sugestões de melhorias usando problemas do GitHub. Vou descrever esse processo.

Modo de comunicação

A maioria dos problemas gerados para ambos os repositórios foram resolvidos usando comunicação síncrona via chamada Discord. Depois disso, conversamos de forma assíncrona usando mensagens do Discord, pois havia um problema difícil para mim agilizar a configuração do meu projeto usando scripts bash, e ligar para meu colega de equipe toda vez que precisava testar se funcionava na máquina dele parecia desnecessário. Testar usando contêineres Docker e subsistema WSL Linux em minha máquina não foi o mesmo que testá-los no sistema de Al e destacou bugs importantes.

Experiência de revisar o código de alguém

Não experimentei nada incomum ao revisar o código do meu colega de equipe, pois tenho muita experiência com desenvolvimento em Node.JS. Eu gostava de criar problemas e imediatamente sugerir soluções para eles. Um problema que tivemos é que não conseguimos descobrir uma maneira de me permitir colocar rótulos nas questões que criei, apenas Al poderia fazer isso, o que foi irritante.

Experiência de alguém revisando meu código

Al sugeriu muito espaço para melhorias, principalmente com a instalação da minha ferramenta CLI. Quando ele bifurcou meu repositório pela primeira vez, era um requisito que os usuários finais instalassem manualmente uma versão específica do python, o que é definitivamente uma tarefa frustrante. Além disso, ele destacou outras possíveis melhorias para o uso conveniente de uma ferramenta, como a introdução do arquivo .env para que você não precise inserir sua chave de API toda vez que iniciar a ferramenta. Gosto de receber informações de outras pessoas sobre meu código porque isso me permite crescer como desenvolvedor e definitivamente expande minha visão do ciclo de vida de desenvolvimento.

Problemas durante a revisão e teste

A maioria dos problemas que tivemos foram com minha ferramenta, porque o programa CLI do Al foi escrito em Node.JS e nós dois temos muita experiência com ele. Por outro lado, nós dois não gostamos do ecossistema Python, então tivemos muitos problemas para interagir com ele. Ao testar o repositório de Al, achei os documentos escritos em seu README enganosos ou confusos de entender, especialmente as opções de modelo e chave de API. Tivemos que passar por um processo de tentativa e erro para descobrir quais chaves e modelos de API são aceitos por sua ferramenta. Quando se trata de testar meu repositório, a versão do python no sistema do Al estava muito desatualizada (2.7), então ele teve que instalar a 3.10.6 (versão necessária para usar minha ferramenta) manualmente. Porém, mesmo assim os problemas não terminaram. Mesmo tendo instalado, ele ainda não estava sendo reconhecido pelo ambiente virtual que minha ferramenta cria com pipenv. Depois disso, também ficamos frustrados ao inserir a chave API necessária para o uso da minha ferramenta sempre que a iniciávamos. Por fim, os documentos README não ajudaram na instalação. Tentamos segui-los, mas continuamos recebendo erros relacionados a alguns scripts que não eram reconhecidos no PATH. Foi aí que decidi que precisávamos de algum tipo de ferramenta de automação que fizesse toda a instalação para você. Uma ideia que tive foi encaixar o aplicativo, mas isso exigiria que eu mapeasse de alguma forma os volumes do Docker para o diretório de saída e os arquivos de entrada especificados para minha ferramenta, e isso complicaria tudo duas vezes. Assim, lembrei-me de que muitos gerenciadores de pacotes são, na verdade, ferramentas de linha de comando e, se você instalá-los clonando um repositório GitHub, será necessário configurá-los executando algum tipo de script de configuração do bash. Então foi essa a ideia que decidi implementar. Finalmente, nós dois não conseguimos descobrir uma maneira de atribuir rótulos como bug ou melhoria aos problemas que registramos.

Problemas que registrei

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 os problemas que encontrei, eles cobriram principalmente casos em que as opções escritas no arquivo README deste projeto não funcionavam de fato ou a maneira como funcionavam era descrita de maneira enganosa.

Problemas que foram registrados em meu repositório

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 os problemas encontrados em meu repositório, eles estavam principalmente relacionados à conveniência de uso de minha ferramenta. Além disso, houve um bug quando você forneceu um arquivo com código-fonte sintaticamente correto para minha ferramenta e ele o identificou como um arquivo que não contém código-fonte válido.

Problemas que consegui corrigir

Resolvi todos os meus problemas. Todos eles levaram menos de 30 minutos para serem corrigidos, mas houve um problema que levei cerca de 2 a 3 horas para corrigir:
https://github.com/SychAndrii/infusion/issues/8

Parece estranho já que o aprimoramento do arquivo README deve ser facilmente alcançável, mas a primeira sugestão de Al exigiu que eu refazesse completamente o processo de instalação da minha ferramenta, o que exigiu que eu introduzisse 2 scripts para instalação - um para bash e um para Powershell. O problema que não consegui resolver na maior parte do tempo foi que, embora esses scripts de configuração instalassem corretamente a versão necessária do python, essa versão do python não era transmitida ao ambiente virtual, no qual você precisa entrar antes de usar minha ferramenta. Eventualmente, eu consertei isso.

O que eu aprendi

Definitivamente melhorei minhas habilidades no README. A maneira como forneci o exemplo de uso foi muito confusa para o usuário final. Além disso, finalmente usei as linguagens bash e powershell para fazer algo sozinho, não para um trabalho escolar, não porque fosse um requisito, mas porque queria simplificar o processo de interação com minha ferramenta. Finalmente, decidi enfrentar a linguagem que absolutamente não suporto - que é python. Trabalhar com ele definitivamente não foi agradável para mim, mas acho que é essencial poder usá-lo se você quiser encontrar um emprego hoje, especialmente com as tendências de IA.