Outil CLI de génération de documents d'infusion

Infusion est un outil open source utilisé pour générer de la documentation dans vos fichiers de code. Il utilise le modèle OpenAI gpt-4 pour rédiger des commentaires. C'était mon projet et je l'ai écrit en Python.

Lien GitHub :
https://github.com/SychAndrii/infusion

explainer.js est un outil open source utilisé pour expliquer les extraits de code dans vos fichiers de code. Il utilise des modèles Groq pour rédiger des commentaires. C'était un projet de mon coéquipier @aamfahim et il l'a écrit en Node.JS

Lien GitHub :
https://github.com/aamfahim/explainer.js

Je suis actuellement inscrit à un cours open source à Seneca Polytechnic, où nous avons été chargés de faire équipe avec une autre personne, de réviser le code de chacun et de donner quelques suggestions d'amélioration en utilisant les problèmes GitHub. Je vais décrire ce processus.

Mode de communication

La plupart des problèmes générés pour les deux référentiels ont été résolus en utilisant une communication synchrone via un appel Discord. Après cela, nous avons parlé de manière asynchrone en utilisant les messages Discord, car il y avait un problème difficile pour moi de rationaliser la configuration de mon projet à l'aide de scripts bash, et appeler mon coéquipier à chaque fois que j'avais besoin de tester si cela fonctionnait sur sa machine semblait inutile. Tester à l'aide de conteneurs Docker et du sous-système WSL Linux sur ma machine n'était pas la même chose que de les tester sur le système d'Al, et cela a mis en évidence des bugs importants.

Expérience de révision du code de quelqu'un

Je n'ai rien ressenti d'inhabituel lors de la révision du code de mon coéquipier, car j'ai beaucoup d'expérience avec le développement Node.JS. J'aimais créer des problèmes, puis leur suggérer immédiatement des solutions. Un problème que nous avions était que nous ne parvenions pas à trouver un moyen de me permettre de mettre des étiquettes sur les problèmes que j'avais créés, seul Al pouvait le faire, ce qui était ennuyeux.

Expérience de quelqu'un révisant mon code

Al a suggéré beaucoup de choses à améliorer, notamment avec l'installation de mon outil CLI. Lorsqu'il a créé mon dépôt pour la première fois, les utilisateurs finaux étaient tenus d'installer manuellement une version particulière de Python, ce qui est définitivement une tâche frustrante. De plus, il a souligné d'autres améliorations possibles pour une utilisation pratique d'un outil, comme l'introduction du fichier .env afin que vous n'ayez pas à saisir votre clé API à chaque fois que vous démarrez l'outil. J'aime recevoir l'avis d'autres personnes sur mon code, car cela me permet d'évoluer en tant que développeur et cela élargit définitivement ma vision du cycle de vie du développement.

Problèmes lors de l'examen et des tests

La plupart des problèmes que nous avons rencontrés concernaient mon outil, car le programme CLI d'Al a été écrit en Node.JS et nous en avons tous les deux beaucoup d'expérience. En revanche, nous n’aimons pas tous les deux l’écosystème Python, nous avons donc eu beaucoup de difficultés à interagir avec lui. Lors du test du référentiel d'Al, j'ai trouvé que les documents écrits dans son README étaient trompeurs ou déroutants à comprendre, en particulier le modèle et les options de clé API. Nous avons dû passer par un processus d'essais et d'erreurs pour déterminer quelles clés et modèles API sont acceptés par son outil. Lorsqu'il s'agissait de tester mon référentiel, la version de python sur le système d'Al était très obsolète (2.7), il a donc dû installer la 3.10.6 (version requise pour utiliser mon outil) manuellement. Cependant, même alors, les problèmes n’ont pas pris fin. Même s'il l'a installé, il n'était toujours pas reconnu par l'environnement virtuel créé par mon outil avec pipenv. Après cela, nous avons également été frustrés de saisir la clé API requise pour l'utilisation de mon outil à chaque fois que nous le démarrions. Enfin, la documentation README n'a pas aidé à l'installation. Nous avons essayé de les suivre, mais nous avons continué à recevoir des erreurs liées à certains scripts non reconnus sur le PATH. C'est à ce moment-là que j'ai décidé que nous avions besoin d'une sorte d'outil d'automatisation qui effectue toute l'installation pour vous. Une de mes idées était de dockeriser l'application, mais cela m'obligerait alors à mapper d'une manière ou d'une autre les volumes Docker au répertoire de sortie et aux fichiers d'entrée spécifiés pour mon outil, ce qui compliquerait tout deux fois. Ainsi, je me suis souvenu que de nombreux gestionnaires de packages sont en fait des outils de ligne de commande, et si vous les installez en clonant un dépôt GitHub, vous devez alors les configurer en exécutant une sorte de script de configuration bash. C’est donc l’idée que j’ai décidé de mettre en œuvre. Finalement, nous n'avons pas trouvé de moyen d'attribuer des étiquettes telles que bug ou amélioration aux problèmes que nous avons déposés.

Problèmes que j'ai déposés

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

Pour résumer les problèmes que j'ai trouvés, ils couvraient principalement des cas où les options écrites dans le fichier README de ce projet ne fonctionnaient pas réellement, ou la façon dont elles fonctionnaient était décrite de manière trompeuse.

Problèmes déposés sur mon dépôt

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

Pour résumer les problèmes trouvés dans mon dépôt, ils étaient principalement liés à la commodité d'utilisation de mon outil. De plus, il y a eu un bug lorsque vous avez fourni un fichier avec un code source syntaxiquement correct à mon outil, et il l'a identifié comme un fichier ne contenant pas de code source valide.

Problèmes que j'ai réussi à résoudre

J'ai résolu tous mes problèmes. Tous ont pris moins de 30 minutes à résoudre, mais il y avait un problème qui m'a pris environ 2-3 heures à résoudre :
https://github.com/SychAndrii/infusion/issues/8

Cela semble bizarre puisque l'amélioration du fichier README devrait être facilement réalisable, mais la première suggestion d'Al m'a obligé à refaire complètement le processus d'installation de mon outil, ce qui m'a obligé à introduire 2 scripts pour l'installation - un pour bash et un pour Powershell. Le problème que je n'ai pas pu résoudre la plupart du temps était que même si ces scripts d'installation installaient correctement la version requise de Python, cette version de Python n'était pas transmise à l'environnement virtuel, que vous devez entrer avant d'utiliser mon outil. Finalement, j’ai résolu ce problème.

Ce que j'ai appris

J'ai définitivement amélioré mes compétences README. La façon dont j'ai fourni un exemple d'utilisation était très déroutante pour l'utilisateur final. De plus, j'ai finalement utilisé les langages bash et PowerShell pour faire quelque chose moi-même, non pas pour un devoir scolaire, non pas parce que c'était une exigence, mais parce que je voulais simplifier le processus d'interaction avec mon outil. Finalement, j'ai décidé d'affronter un langage que je ne supporte absolument pas, à savoir le python. Travailler avec n'était certainement pas agréable pour moi, mais je pense qu'il est essentiel de pouvoir l'utiliser si vous voulez trouver un emploi aujourd'hui, surtout avec la tendance de l'IA.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!