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

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

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

• リフレクション (これ)
• 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 Provider Sync

以上がフライデー ハックからリリースまで: オープンソース プロジェクトの作成とリリースについての考察の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。