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

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

• リフレクション (これ)
• 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 などのツールを使用して、さまざまな種類のビルドを作成します。

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

スコープを維持する

たくさん実験するつもりでしたが、Go については全くの初心者だったので、構造化されていない作業が多くなるだろうと思っていました。
ここでスコープを設定することが重要でした。アルファ リリースはいつ頃が適切ですか?
私は早い段階でどのような機能を持たせるべきかを決めました。そして、座って改良し、さらに拡張することは魅力的ですが、これは良かったです。
これなら長時間座っていられます。

結論: 恥ずかしいと同時に誇りに思うときは、プロジェクトをアルファ版としてリリースしてください。

見積もり – どれくらい難しいでしょうか?

新しい言語の学習は、言語自体の学習の一部ではありますが、エコシステムとそのイディオムを学ぶことの方がはるかに重要です。
どのようなライブラリが使用され、どのように使用され、あれやこれやを行う慣用的な方法は何ですか?
このプロジェクトでは、学習と研究に多くの時間を費やす必要があり、その時間のおそらく 50% は
私が知っている言語とエコシステムでコーディングするだけで過ごしてきました。

結論: 新しいコア スタックを学習し、実験を行う場合は、推定時間を 3 倍します。言語の構文は小さなことです。

作成プロセス

初期コミット

基本的な実装は 1 日で完了しました。ビルド、エラー処理、ドキュメント、エッジケース、保守性などはありませんでした。
金曜日のハッキングのほとんどはここで終わりますが、そのほとんどはそれ以上進むことはありません。

しかし、すべての上級開発者が知っているように、何かを機能させるには、製品のリリースから何マイルもかかります。

もうすぐ終わりますね？あまり。

時間を見つける

特に仕事で疲れ果てた春を迎えていたため、プロジェクトに費やす時間を見つけるのが本当に大変だったことがあります。
特定の内容についての本を 2 時間読みたい、または新しいテクノロジーを学びたいと思うのは、毎晩ではありません。
あるいはドキュメントの作成に時間を費やすこともあります。私には子供も家もあり、プライベートなプロジェクトに他の趣味以上に熱中するわけにはいきませんでした。
しかし、常に何かを与える必要があります。結局、視聴するシリーズが減り、この期間中はゲームがほとんどなくなりました。

そうは言っても、プロジェクトにもっと時間を費やすことができればよかったのですが、ほとんどの場合、それがモチベーションになりました - 睡眠時間を減らしてコーディングしたり勉強したりする夜のセッションが数回ありました。
もっと先に進むことにとても興奮していたからです。また、ウェイトリフティング、本の執筆、開発など、何かが楽しいときは楽しいのです。

忘れたもの

私は長い間、チームで働くことに慣れてきました。ソロ プロジェクトでは、より多くの作業を管理し、技術的なことはあまりなく、すべての部分で非常に優れている必要があります。
私は、優れた CLI 設計と慣用的な選択を検討するのにかなりの時間を費やしました。もう 1 つの分野は、リリース プロセスとさまざまなプラットフォーム向けのバイナリの構築でした。
SLSA やオープンソースのその他の標準に従うのも時間がかかりました。そして、適切なテスト カバレッジが必要ですよね?
チームで作業すると、他の誰かがあなたが望んでいたロゴを作成し、ドキュメントを作成する必要があることが期待されます。
ソロで働くなら、あなただけでなければ、それは起こりません。
コードを書くことは、プロジェクトを実現することの 50% にもなりません。そして残りがあります。

詐欺師症候群が襲来

詐欺師症候群は、知識ベースの開発者の世界では一般的です。誰もが異なるスキルを持っており、いつでも、あなたよりも詳しい人がいます。
チームにいると、物事について話し合う相手がいます。
一人では、それほど多くはありません。

しかし、コード内で時には愚かなことをすることがあるということを受け入れることが重要です。
そして、オープンソースとは完璧であることが目的ではありません。それは、他の人にとって役立つ可能性のあるものを学び、解決し、リリースすることです。

ザ・グラインド

まあ、何と言えばいいでしょうか - 終わったら終わりです。

深夜のデバッグやリファクタリングが数回ありましたが、フローとドーパミンの数えきれないほどの瞬間もありました。

私にとって、リリースの時は、プロジェクトのアーキテクチャ全体が根本的に変わることはないと感じたときに来ました。インターフェイスを特定し、それが拡張可能であると感じました。
コードベースは問題ありません。
基本的な機能のほとんどはそこにあり、すべてが改善の余地がありますが、まだ取り組むべき基盤です。

余波と教訓

1. スコープを早めに設定します: どこで停止するかを決めます。プロジェクトの構造、ドキュメント、リリース、パイプライン、コミュニティ ガイドラインを早期に設定します。未来のあなたは過去のあなたに感謝するでしょう。

2. ストレスを感じないで、学習プロセスを楽しんでください: 終わったら終わりです。

3. 粘り強く: オープンソースは短距離走ではなくマラソンです。燃え尽きないでください。それは趣味であって、あなたの人生ではありません。ただし、粘り強くやってください。毎日小さなことをしてみましょう。

4. 学んで、学んで、学んで: すべてを問題としてではなく、学習と改善の機会として捉えてください。

5. コーディングは簡単です: メイン コードは最も時間がかからないものです。ドキュメントやテストなど、その他すべての作業に時間が費やされます。

6. 追加の作業を実行します: コーディングと同じくらい楽しいです。はい、ドキュメントさえあれば、説明したり再説明したりする時間を節約できます。退屈なら楽しくしてください。 Docs-as-code、vim-pong など

7. 休憩を取る: 燃え尽き症候群は本物です。必要なときは後退してください。他のクリエイティブな学習プロセスと同様に、バッチで実行してください。

8. システムを使用する: 独自のドッグフードをできるだけ早く実践および現実の世界で使用してください。さらに良いのは、フィードバックを提供できる人/コミュニティを見つけることです。

9. 旅を楽しんでください: 作るのは素晴らしいことです。

10. 完了してください: この世界には、やりかけのプロジェクトが無数にあります。完了してください。

11. AI をヘルプとして使用する: コードの改善の依頼、コード レビュー、ドキュメントの構造、要約など、AI に少しの追加作業を委任することで時間を節約します。ただし、そうしないでください。決して盲目的に信じないでください。回答を確認して批判します。

さて、ハッキングを楽しんで、次は何を作りたいか考えてみましょう!!

リンク

プロジェクト: Git プロバイダー同期