CLI-Tool zur Generierung von Infusionsdokumenten

Infusion ist ein Open-Source-Tool, das zur Erstellung der Dokumentation in Ihren Codedateien verwendet wird. Es verwendet das OpenAI gpt-4-Modell zum Schreiben von Kommentaren. Es war mein Projekt und ich habe es in Python geschrieben.

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

explainer.js ist ein Open-Source-Tool, das zum Erklären von Codeausschnitten in Ihren Codedateien verwendet wird. Es verwendet Groq-Modelle zum Schreiben von Kommentaren. Es war ein Projekt meines Teamkollegen @aamfahim und er hat es in Node.JS geschrieben

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

Ich bin derzeit in einem Open-Source-Kurs am Seneca Polytechnic eingeschrieben, wo wir die Aufgabe hatten, mit einer anderen Person zusammenzuarbeiten, den Code des anderen zu überprüfen und mithilfe von GitHub-Problemen einige Verbesserungsvorschläge zu machen. Ich werde diesen Prozess beschreiben.

Art der Kommunikation

Die meisten der für beide Repositories generierten Probleme wurden durch synchrone Kommunikation per Discord-Aufruf gelöst. Danach unterhielten wir uns asynchron über Discord-Nachrichten, da es für mich schwierig war, die Einrichtung meines Projekts mithilfe von Bash-Skripten zu optimieren, und es mir unnötig erschien, meinen Teamkollegen jedes Mal anzurufen, wenn ich testen musste, ob es auf seinem Computer funktioniert. Das Testen mit Docker-Containern und dem WSL-Linux-Subsystem auf meinem Computer war nicht dasselbe wie das Testen auf Al's System und hat wichtige Fehler hervorgehoben.

Erfahrung mit der Überprüfung des Codes einer anderen Person

Bei der Überprüfung des Codes meines Teamkollegen ist mir nichts Ungewöhnliches aufgefallen, da ich viel Erfahrung mit der Node.JS-Entwicklung habe. Mir gefiel es jedoch, Probleme zu schaffen und dann sofort Lösungen dafür vorzuschlagen. Ein Problem, das wir hatten, war, dass wir keinen Weg finden konnten, es mir zu ermöglichen, die von mir erstellten Probleme mit Etiketten zu versehen. Das konnte nur Al, was ärgerlich war.

Erfahrung von jemandem, der meinen Code überprüft

Al hat viel Raum für Verbesserungen vorgeschlagen, insbesondere bei der Installation meines CLI-Tools. Als er mein Repo zum ersten Mal geforkt hat, mussten die Endbenutzer eine bestimmte Python-Version manuell installieren, was definitiv eine frustrierende Aufgabe ist. Darüber hinaus hob er andere mögliche Verbesserungen für die komfortable Nutzung eines Tools hervor, wie etwa die Einführung einer .env-Datei, damit Sie Ihren API-Schlüssel nicht jedes Mal eingeben müssen, wenn Sie das Tool starten. Ich mag es, von anderen Leuten Input zu meinem Code zu bekommen, weil es mir ermöglicht, mich als Entwickler weiterzuentwickeln, und es definitiv meine Sicht auf den Entwicklungslebenszyklus erweitert.

Probleme beim Überprüfen und Testen

Die meisten Probleme hatten wir mit meinem Tool, da Al's CLI-Programm in Node.JS geschrieben war und wir beide viel Erfahrung damit haben. Im Gegensatz dazu mögen wir beide das Python-Ökosystem nicht, daher hatten wir große Probleme bei der Interaktion damit. Als ich Al's Repository testete, stellte ich fest, dass die in seiner README-Datei geschriebenen Dokumente irreführend oder verwirrend waren, insbesondere die Modell- und API-Key-Optionen. Wir mussten den Prozess der Versuche und Irrtümer durchlaufen, um herauszufinden, welche API-Schlüssel und -Modelle von seinem Tool akzeptiert werden. Als es darum ging, mein Repository zu testen, war die Python-Version auf Al's System sehr veraltet (2.7), sodass er 3.10.6 (Version, die für die Verwendung meines Tools erforderlich ist) manuell installieren musste. Doch selbst dann hörten die Probleme nicht auf. Obwohl er es installierte, wurde es von der virtuellen Umgebung, die mein Tool mit pipenv erstellt, immer noch nicht erkannt. Danach waren wir auch frustriert darüber, bei jedem Start den für die Nutzung meines Tools erforderlichen API-Schlüssel eingeben zu müssen. Schließlich haben die README-Dokumente bei der Installation nicht geholfen. Wir haben versucht, ihnen zu folgen, bekamen aber immer wieder Fehler, die darauf zurückzuführen waren, dass einige Skripte im PATH nicht erkannt wurden. Da habe ich beschlossen, dass wir eine Art Automatisierungstool brauchen, das die gesamte Installation für Sie erledigt. Ein Gedanke, den ich hatte, war, die Anwendung zu dockerisieren, aber dann müsste ich Docker-Volumes irgendwie dem Ausgabeverzeichnis und den Eingabedateien zuordnen, die für mein Tool angegeben sind, und das würde alles doppelt komplizieren. Daher fiel mir ein, dass es sich bei vielen Paketmanagern eigentlich um Befehlszeilentools handelt. Wenn Sie sie durch Klonen eines GitHub-Repositorys installieren, müssen Sie sie durch Ausführen einer Art Bash-Setup-Skript einrichten. Das war also die Idee, die ich in die Tat umsetzen wollte. Schließlich konnten wir beide keine Möglichkeit finden, den von uns eingereichten Problemen Bezeichnungen wie „Fehler“ oder „Verbesserung“ zuzuweisen.

Von mir eingereichte Probleme

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

Um die von mir gefundenen Probleme zusammenzufassen: Sie betrafen hauptsächlich Fälle, in denen Optionen, die in der README-Datei dieses Projekts geschrieben waren, nicht tatsächlich funktionierten oder ihre Funktionsweise irreführend beschrieben wurde.

Probleme, die in meinem Repo eingereicht wurden

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

Um die in meinem Repo gefundenen Probleme zusammenzufassen: Sie bezogen sich hauptsächlich auf die Benutzerfreundlichkeit meines Tools. Darüber hinaus gab es einen Fehler, als Sie meinem Tool eine Datei mit syntaktisch korrektem Quellcode übermittelten und es sie als eine Datei identifizierte, die keinen gültigen Quellcode enthielt.

Probleme, die ich beheben konnte

Ich habe alle meine Probleme behoben. Die Behebung aller Probleme dauerte weniger als 30 Minuten, aber es gab ein Problem, für dessen Behebung ich etwa 2-3 Stunden brauchte:
https://github.com/SychAndrii/infusion/issues/8

Es scheint seltsam, da eine Erweiterung der README-Datei leicht zu erreichen sein sollte, aber was der erste Vorschlag von Al erforderte, war, dass ich den Installationsprozess meines Tools komplett neu gestalten musste, was erforderte, dass ich zwei Skripte für die Installation einführte – eines für Bash und eines für Bash eine für Powershell. Das Problem, das ich die meiste Zeit nicht lösen konnte, bestand darin, dass diese Setup-Skripte zwar die erforderliche Python-Version ordnungsgemäß installierten, diese Python-Version jedoch nicht an die virtuelle Umgebung weitergegeben wurde, in die Sie vor der Verwendung meines Tools eintreten müssen. Irgendwann habe ich das aber behoben.

Was ich gelernt habe

Ich habe meine README-Kenntnisse definitiv verbessert. Die Art und Weise, wie ich Beispielverwendungen bereitgestellt habe, war für den Endbenutzer sehr verwirrend. Außerdem habe ich endlich Bash- und Powershell-Sprachen verwendet, um selbst etwas zu tun, nicht für eine Schulaufgabe, nicht weil es eine Anforderung war, sondern weil ich den Prozess der Interaktion mit meinem Tool vereinfachen wollte. Schließlich habe ich beschlossen, mich der Sprache zu stellen, die ich absolut nicht ausstehen kann – nämlich Python. Die Arbeit damit hat mir definitiv keinen Spaß gemacht, aber ich denke, es ist wichtig, es nutzen zu können, wenn man heute einen Job finden möchte, insbesondere im Hinblick auf den KI-Trend.

Das obige ist der detaillierte Inhalt vonCLI-Tool zur Generierung von Infusionsdokumenten. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!