Vom Freitags-Patch-Hack bis zur Veröffentlichung: Überlegungen zum Erstellen und Veröffentlichen eines Open-Source-Projekts
Dies ist Teil einer Reihe, die sich an Anfänger und fortgeschrittene Entwickler richtet, die ihre Ideen als Open-Source-Projekte veröffentlichen oder daran interessiert sind.
Diese Überlegungen sind voreingenommen und persönlich. Weitere Artikel sind geplant. Durch das Teilen einiger Überlegungen hoffe ich, Sie zu eigenen Projekten zu inspirieren
- Reflexionen (dies)
- Go-Lang lernen als Java-Entwickler (TODO)
- Open-Source-Gesundheits- und Community-Dateien (TODO)
- Open Source Security (TODO)
Die Bedürfnisse
Alles begann vor Jahren. Hin und wieder brauchte ich etwas, bei dem es immer darum ging, das gleiche alte Bash-Skript neu zu erstellen, entweder von mir oder jemand anderem.
Die allgemeinen Anforderungen waren einfach, da sie oft auf einem hohen Niveau liegen.
Was wir Entwickler meistens tun, ist eigentlich nur, Informationen von Punkt A nach Punkt B zu verschieben, oder?
Hier bestand das Ziel darin, eine Reihe von Git-Repositorys zu spiegeln – auf einen anderen Git-Anbieter, auf die Festplatte, in ein Archivformat, in einer CLI-App.
Das brauchte ich privat und beruflich. Ich habe erlebt, dass Menschen Probleme damit hatten, viel Zeit damit zu verbringen, diese Dinge manuell zu erledigen, und das stört mich.
Dennoch schien es immer ein einfaches Bash-Skript zu bleiben. Schnell erledigt, aber sobald noch etwas hinzugefügt werden musste – Sonderfälle, Fehlerbehandlung, Modularisierung, Paketierung usw. – halten Bash-Skripte größeren Tools nicht stand, wie die meisten von uns zustimmen würden.
Also habe ich beschlossen, eine vollständige CLI-Anwendung dafür zu erstellen.
Die zu treffenden Vorentscheidungen
Gibt es ein solches Tool bereits?
Das erste, was wir tun mussten, war, das Rad nicht neu zu erfinden.
Es gibt einige Tools, die Open Source sind und dieses Problem lösen. Mindestens eines in Go geschrieben, ein paar Bash-Skripte und wenn man das mitzählt, Importfunktionen wie die in Gitea.
Ich habe sie ausprobiert, aber ich konnte keines finden, das genau so funktionierte, wie ich es wollte. Und da ich andere Vorstellungen davon hatte, wohin ich das Projekt führen wollte, beschloss ich, nicht näher darauf einzugehen
Wir beginnen mit der Anwendung von Patches auf die bestehenden Projekte.
Es gibt auch ein paar kommerzielle Tools, aber ich hatte das Gefühl, dass dieses kleine Tool auch in Open-Source-Formen existieren sollte.
Fazit: Es gab einen Platz für dieses CLI-Tool auf dieser Welt.
Bei Work-Hackdays oder in der privaten Freizeit darauf hacken?
Wir haben am Ende von Sprints und bei anderen Gelegenheiten Hacking-Zeiten bei der Arbeit. Ein Ansatz wäre, bei diesen Gelegenheiten im Laufe der Zeit daran herumzuhacken und daraus etwas Nützliches zu machen.
Ich habe mich aus folgenden Gründen schnell dafür entschieden, es stattdessen komplett in meiner privaten Freizeit zu machen:
- Hack-Gelegenheiten am Arbeitsplatz sollten für kurze Lern- und Kreativitätsschübe genutzt werden, nicht für die langfristige Ausarbeitung eines vollständigen Projekts.
- Die Lösung passt nicht in das Geschäft der Kernorganisation – wenn ja, wäre sie dort immer eine seltsame Ente.
- Wenn man es an die Arbeit koppelt, fühlt es sich einfach wie mehr Arbeit an – ich mache das zum Spaß und zum Lernen von Go usw. – es würde Druck und Stress auf mich ausüben.
- Es würde ewig dauern, es an den Arbeitstagen zu erledigen. Ein paar Stunden, über Wochen verteilt.
Fazit:Ich sollte es in meiner Freizeit zum Spaß machen.
Wahl des Technologie-Stacks
Ich habe im Laufe der Jahre die meiste Zeit in der Java/Kotlin-Welt verbracht, mit ein paar Projekten in JS/TS, Python/Ruby, und wie jeder erfahrene Entwickler habe ich mich ab und zu auch mit anderen Dingen beschäftigt.
Ich wollte aber schon lange unbedingt Go und/oder Rust lernen. Dies wäre also eine Gelegenheit, die Motivation zu bekommen, in eine neue Sprache einzutauchen
Der Grund, warum ich mich für Go entschieden habe, ist, dass eine ganze Reihe von CLI-Anwendungen in der Open-Source-DevOps-Welt darin geschrieben sind und ich in der Lage sein möchte, gelegentlich Patches an Projekte von Drittanbietern einzureichen. Außerdem bedeutet das Schreiben in Go eine Binärdatei mit vielen Zielarchitekturen.
Ich hätte dies zum Beispiel in Java tun können, mit Pico CLI und GraalVM, von denen ich seit früheren Versuchen einen guten Eindruck hatte, aber ich entschied, dass ich stattdessen unbedingt Go lernen wollte.
Fazit:Ich sollte es in Go machen und daraus lernen.
Andere Lernziele
Damit wollte ich auch tiefer in die Themen der Bereitstellung eines gut verpackten Open-Source-Projekts eintauchen und dabei die meisten Sicherheitspraktiken befolgen – Scorecards, SLSA,
und die Verwendung von Tools wie GoRelease zum Erstellen verschiedener Builds.
Fazit: Nutzen Sie die Gelegenheit, Themen Ihrer Wahl zu lernen und zu vertiefen.
Behalten Sie den Umfang
Da ich vorhatte, viel zu experimentieren, und Go noch völlig neu für mich war, wusste ich, dass ich viel unstrukturierte Arbeit leisten würde.
Hier war es wichtig, den Umfang festzulegen – wann wäre er gut genug für eine Alpha-Veröffentlichung?
Ich habe schon früh entschieden, welche Funktionalität es haben sollte, und so verlockend es auch war, es zu verfeinern und weiter zu erweitern, es war gut.
Ich könnte lange damit sitzen.
Fazit: Geben Sie das Projekt als Alpha frei, wenn Sie gleichermaßen verlegen und stolz darauf sind.
Schätzung – wie schwer kann es sein?
Das Erlernen einer neuen Sprache ist ein kleiner Teil des Erlernens der Sprache selbst, aber viel mehr geht es um das Erlernen des Ökosystems und seiner Redewendungen.
Welche Bibliotheken werden verwendet, wie werden sie verwendet, welche idiomatischen Methoden gibt es, dies und das zu tun?
Ich müsste während dieses Projekts viel Zeit mit Lernen und Recherchieren verbringen, vielleicht 50 % der Zeit
Ich habe nur damit verbracht, in einer Sprache und einem Ökosystem zu programmieren, die ich kenne.
Fazit: Multiplizieren Sie Ihre geschätzte Zeit mit drei, wenn Sie neue Core-Stacks erlernen und experimentieren. Die Sprachsyntax wird die Kleinigkeit sein.
Der Schöpfungsprozess
Erster Commit
Die grundlegende Implementierung war an einem Tag erledigt – es gab keine Builds, Fehlerbehandlung, Dokumentation, Randfälle, Wartbarkeit usw.
Hier enden die meisten Freitags-Hacks, und die meisten gehen nie weiter.
Aber wie alle leitenden Entwickler wissen, ist es weit von der Veröffentlichung eines Produkts entfernt, etwas zum Laufen zu bringen.
Bald fertig, oder? Nicht wirklich.
Die Zeit finden
Manchmal war es wirklich schwer, Zeit für das Projekt zu finden, vor allem, weil ich einen anstrengenden Frühling bei der Arbeit hatte.
Man hat nicht jeden Abend Lust, zwei Stunden lang ein Buch über etwas Bestimmtes zu lesen oder eine neue Technik zu erlernen.
Oder Zeit damit verbringen, Dokumentationen zu schreiben. Ich habe Kinder und ein Haus, und ich könnte es mir nicht leisten, dass ein privates Projekt mich mehr in Anspruch nimmt als andere Hobbys.
Aber irgendetwas muss immer nachgeben – ich habe am Ende weniger Serien geschaut und Spiele gab es in dieser Zeit fast nicht.
Trotzdem wünschte ich, ich könnte mehr Zeit mit dem Projekt verbringen, aber es war fast immer motivierend – ich hatte ein paar Nachtsitzungen, in denen ich weniger schlief und programmierte oder lernte,
weil ich so aufgeregt war, weiterzukommen. Und wenn etwas Spaß macht, dann macht es auch Spaß, sei es das Heben von Gewichten, das Schreiben eines Buches, das Entwickeln usw.
Die Dinge, die ich vergessen habe
Ich bin es schon lange so gewohnt, in Teams zu arbeiten. Bei einem Soloprojekt muss man viel mehr Aufgaben bewältigen und in jedem Teil davon ziemlich gut sein, nicht oft technisch.
Ich habe ziemlich viel Zeit damit verbracht, mich mit gutem CLI-Design und idiomatischen Entscheidungen zu beschäftigen. Ein weiterer Bereich war der Veröffentlichungsprozess und die Erstellung von Binärdateien für verschiedene Plattformen.
Auch die Befolgung von SLSA und anderen Standards in Open Source nahm Zeit in Anspruch. Und wir wollen eine gute Testabdeckung, oder?
Wenn Sie im Team arbeiten, wird hoffentlich jemand anderes das von Ihnen gewünschte Logo erstellen und die erforderliche Dokumentation erstellen.
Wenn du alleine arbeitest, bist nur du dran, sonst passiert es nicht.
Das Schreiben von Code macht nicht einmal 50 % der Projektabwicklung aus. Und da ist noch der Rest.
Das Hochstapler-Syndrom schlägt zu
Das Hochstapler-Syndrom ist in unserer wissensbasierten Entwicklerwelt weit verbreitet. Jeder hat unterschiedliche Fähigkeiten und es wird immer jemanden geben, der mehr weiß als Sie.
Wenn man in einem Team ist, hat man jemanden, mit dem man Dinge besprechen kann.
Alleine nicht so sehr.
Aber es geht darum zu akzeptieren, dass man manchmal ein paar dumme Dinge im Code macht.
Und bei Open Source geht es nicht darum, perfekt zu sein. Es geht darum, Dinge zu lernen, zu lösen und freizugeben, die für andere von Nutzen sein könnten.
Der Grind
Nun, was soll ich sagen – es ist fertig, wenn es fertig ist.
Es gab ein paar späte Nächte mit Debuggen und Umgestalten, aber auch unzählige Momente voller Flow und Dopamin.
Für mich kam die Veröffentlichungszeit, als ich das Gefühl hatte, dass sich die Gesamtarchitektur im Projekt nicht radikal ändern würde – ich hatte die Schnittstellen identifiziert und hatte das Gefühl, dass sie erweiterbar ist.
Die Codebasis ist in Ordnung.
Die meisten Grundfunktionen sind vorhanden, und obwohl alles verbesserungswürdig ist, ist es immer noch eine Basis, an der man arbeiten kann.
Die Folgen und gewonnenen Erkenntnisse
Legen Sie den Umfang frühzeitig fest: Entscheiden Sie, wo Sie aufhören möchten. Richten Sie frühzeitig Ihre Projektstruktur, Dokumentation, Releases, Pipelines und Community-Richtlinien ein. In der Zukunft wirst du es dir danken.
Mach dir keinen Stress, genieße den Lernprozess:Es ist fertig, wenn es fertig ist.
Seien Sie hartnäckig: Open Source ist ein Marathon, kein Sprint. Nicht ausbrennen. Es ist ein Hobby, nicht dein Leben. Seien Sie jedoch hartnäckig. Machen Sie jeden Tag eine kleine Sache.
Lernen, lernen, lernen:Sehen Sie alles als Chance zum Lernen und Verbessern, nicht als Problem.
Codieren ist der einfache Teil: Der Hauptcode ist das, was Sie am wenigsten Zeit in Anspruch nehmen wird; Alles andere, wie Dokumentation, Tests usw., ist Zeitverschwendung.
Machen Sie die Extras: Sie machen genauso viel Spaß wie Programmieren. Ja, selbst die Dokumentation kann Ihnen stundenlanges Erklären und erneutes Erklären ersparen. Machen Sie es lustig, wenn es Sie langweilt. Docs-as-Code, Vim-Pong usw.
Machen Sie Pausen: Burnout ist real. Treten Sie zurück, wenn es nötig ist. Machen Sie es, wie jeden anderen kreativen Lernprozess, stapelweise.
Nutzen Sie das System: Nutzen Sie Ihr eigenes Hundefutter so früh wie möglich in der Praxis und in der realen Welt. Noch besser: Finden Sie eine Person/Community, die Feedback gibt.
Genieße die Reise:Es ist wunderbar zu kreieren.
Schließen Sie es ab: Es gibt zig Millionen zur Hälfte abgeschlossene Projekte auf dieser Welt. Vervollständigen Sie es.
Verwenden Sie KI als Hilfe: Ich spare Stunden, indem ich ein paar Extras an sie delegiere, wie z. B. die Bitte um Codeverbesserungen, Codeüberprüfungen, Dokumentstrukturen, Zusammenfassungen usw. Tun Sie das jedoch nicht Vertraue ihm jemals blind. Überprüfen und kritisieren Sie die Antworten.
Nun, viel Spaß beim Hacken und jetzt überlegen Sie, was Sie als Nächstes machen möchten!!
Links
Das Projekt: Git Provider Sync
Das obige ist der detaillierte Inhalt vonVom Freitags-Hack bis zur Veröffentlichung: Überlegungen zum Erstellen und Veröffentlichen eines Open-Source-Projekts. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
