Vom Freitags-Hack bis zur Veröffentlichung: Überlegungen zum Erstellen und Veröffentlichen eines Open-Source-Projekts

フライデーパッチハックからリリースまで: オープンソースプロジェクトの作成とリリースについての考察

これは、アイデアをオープンソース プロジェクトとしてリリースする、またはリリースすることで興味をそそられる初心者および中級の開発者を対象としたシリーズの一部です。
これらの考察は偏見があり、個人的なものです。さらに多くの記事が予定されています。いくつかの反省を共有することで、あなたが独自のプロジェクトを行うきっかけになれば幸いです

• リフレクション (これ)
• Java 開発者として Go lang を学ぶ (TODO)
• オープンソースのヘルスおよびコミュニティ ファイル (TODO)
• オープンソース セキュリティ (TODO)

ニーズ

すべては数年前に始まりました。私は時折、私または他の誰かによって、同じ古い Bash スクリプトを常に再作成する必要があると思われるものが必要になりました。
多くの場合、高レベルであるため、全体的な要件はシンプルでした。
私たち開発者が主に行っていることは、実際にはポイント A からポイント B に情報をシャッフルすることだけですよね?

ここでの目標は、CLI アプリで、多数の Git リポジトリを別の Git プロバイダー、ディスク、アーカイブ形式にミラーリングすることでした。
これはプライベートでも仕事でも必要でした。こういったことを手動で行うのに多くの時間を費やして苦労している人を見てきましたが、それが私を悩ませています。

それでも、それは常に単純な Bash スクリプトのままであるように見えました。すぐに完了しましたが、特別なケース、エラー処理、モジュール化、パッケージ化など、何か余分なものを追加する必要があるとすぐに、私たちのほとんどが同意するように、Bash スクリプトはより大きなツールには耐えられません。

そこで、完全な CLI アプリケーションを作成することにしました。

事前に行うべき決定

そのようなツールはすでに存在しますか?

最初にすべきことは、車輪の再発明をしないことでした。
この問題を解決するオープンソースのツールがいくつか存在します。少なくとも 1 つは Go で書かれ、いくつかの Bash スクリプト、そして Gitea のようなインポート機能も考慮します。
試してみましたが、私が望んでいたように完全に機能するものは見つかりませんでした。そして、プロジェクトをどこに進めたいかについては別のアイデアがあったので、深く掘り下げないことにしました
既存のプロジェクトへのパッチの適用を開始します。

商用ツールもいくつか存在しますが、この小さなツールはオープンソース形式でも存在すべきだと感じました。

結論: この世界には、この CLI ツールのための場所がありました。

仕事のハックデイやプライベートの自由時間にハッキングしていますか?

私たちは仕事中にスプリントの終わりやその他の機会にハッキングの時間を設けています。 1 つのアプローチは、このような機会に時間をかけてハッキングし、役立つものに作り上げることです。
私はすぐに、次の理由から、プライベートな空き時間に完全にそれを行うことに決めました:

• 職場でのハックの機会は、プロジェクト全体を長期にわたって構築するためではなく、短期間の学習と創造性の爆発のために使用されるべきです。
• そのソリューションは中核組織のビジネスに適合しません。もしそうなら、それは常に変なカモになるでしょう。
• それを仕事に結びつけると、ただの仕事が増えただけのように感じられてしまうでしょう - 私は楽しみと Go などを学ぶためにこれをやっているのです - それは私にプレッシャーとストレスを与えるでしょう。
• 仕事の休日にそれを行うと、永遠に時間がかかります。数時間、数週間にわたって続きます。

結論: 暇なときに楽しくやるべきです。

テクノロジースタックの選択

私は長年にわたってほとんどの時間を Java/Kotlin の世界に費やし、JS/TS、Python/Ruby のいくつかのプロジェクトに取り組み、すべての上級開発者と同様に、時には他のプロジェクトにも手を出してきました。
しかし、私は長い間、Go や Rust を本格的に学びたいと思っていました。したがって、これは新しい言語に飛び込む動機を得る機会となるでしょう
私が Go を選んだ理由は、オープンソース DevOps の世界のかなりの数の CLI アプリケーションが Go で書かれており、場合によってはサードパーティ プロジェクトにパッチを送信できるようにしたいからです。また、Go で書くということは、多くのターゲット アーキテクチャを持つ 1 つのバイナリを意味します。

これは、たとえば、Pico CLI と GraalVM を使用して Java で行うこともできました。以前に試したときから良い印象を持っていましたが、代わりに Go を本当に学びたいと決心しました。

結論: Go で実行し、そこから学ぶべきです。

その他の学習目標

これに伴い、スコアカード、SLSA、

などのセキュリティ慣行のほとんどに従って、適切にパッケージ化されたオープンソース プロジェクトを提供するという主題についてもさらに深く掘り下げたいと思いました。 また、GoRelease などのツールを使用して、さまざまな種類のビルドを作成します。

結論: 選択したトピックを学び、掘り下げる機会を利用してください。

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, die 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ß, egal ob es darum geht, Gewichte zu heben, ein Buch zu schreiben, sich weiterzuentwickeln 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

1. 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.

2. Mach dir keinen Stress, genieße den Lernprozess:Es ist fertig, wenn es fertig ist.

3. 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.

4. Lernen, lernen, lernen:Sehen Sie alles als Chance zum Lernen und Verbessern, nicht als Problem.

5. 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.

6. 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.

7. Machen Sie Pausen: Burnout ist real. Treten Sie zurück, wenn es nötig ist. Machen Sie es, wie jeden anderen kreativen Lernprozess, stapelweise.

8. 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.

9. Genieße die Reise:Es ist wunderbar zu kreieren.

10. Schließen Sie es ab: Es gibt zig Millionen zur Hälfte abgeschlossene Projekte auf dieser Welt. Vervollständigen Sie es.

11. 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!