興味のあるオープンソースプロジェクトを見つける方法最初のステップは、オープンソースを作成する目的を明確にすることです。
もっと実際的に言えば、特定のプロジェクトのコミッター/PMC になることです。
最初の 3 つのタイプはすべて同じ目標、つまり自分自身を向上し、それに伴う利益を得ること、最後のタイプは純粋に情熱から生まれるものであると私は考えています。 個人的には、私は両方に少し当てはまります。ほとんどの人は最初の 3 つのカテゴリの目標を持っていると思うので、まずはそれに冷水をかけなければならないかもしれません。
特に、プロジェクトがより大規模で専門的であればあるほど（あなたもこのようなよく知られたプロジェクトに参加したいと思うでしょう）。 なぜなら、ほとんどのオープンソース コミュニティは、インスタント メッセージの迅速なフィードバックとは異なり、非同期通信を実行し、多くのレビュー担当者が異なるタイム ゾーンに存在しているからです。 ですから、最初から現実的な期待を持つべきです。私がプロジェクトにすごくクールな機能を提出したからといって、すぐにレビューされてマージされ、コミット権限が与えられるなどと期待しないでください。 さらに、Pulsar、Golang、Kafka など、多くのオープンソース プロジェクトは単一の企業によって主導されています。外部コミュニティからの新規参入者に対してあまり配慮が見られない場合があり、PR が何ヶ月も放置されて対応されないことも珍しくありません。 したがって、最初にプロジェクトを選択するときは、次の選択基準を使用することをお勧めします。
写真 写真 先ほど述べた基準に最も適合すると思われるプロジェクトをいくつか紹介します。
オープンソースプロジェクトをすぐに始める方法貢献したいプロジェクトを見つけたが、まだよく知らない場合は、次の手順を試してすぐに始めることができます。 ユニットテストまず最初にユニットテストです。ユニットテストは新しいオープンソースプロジェクトを始めるのに最適な方法ですが、重要なのは既存のユニットテストを見るのではなく、独自のユニットテストを作成することです✍️。 ユニットテストを書いたことがある人なら誰でも、90%以上のカバレッジを達成するには、記述するコードのすべての行を理解する必要があることをご存知でしょう。場合によっては、コードの作成中に不要なコードが見つかることもあり、ビジネスロジックを再検討するのに役立ちます。 したがって、ユニットテストを書くことは確かにプロジェクトに慣れるための迅速な方法ですが、これは単純なロジックを持つプロジェクトにのみ適しています。複雑なビジネスロジックを持つプロジェクトの場合は、公式に推奨されている機能の1つを簡単に実行することをお勧めします。 パルサーを例に挙げましょうApache Pulsarを例に挙げましょう。まずはメッセージプロデューサーとコンシューマーのデモを実行してみましょう。正常に実行されたら、既存のクライアントユニットテストコードを確認し、アサーションをいくつか変更してみてください。この時点で、期待値がなぜそのように定義されているのかがわかるでしょう。 [https://github.com/apache/pulsar/blob/631b13ad23d7e48c6e82d38f97c23d129062cb7c/pulsar-broker/src/test/java/org/apache/pulsar/client/impl/BrokerClientIntegrationTest.java#L1077](https://github.com/apache/pulsar/blob/631b13ad23d7e48c6e82d38f97c23d129062cb7c/pulsar-broker/src/test/java/org/apache/pulsar/client/impl/BrokerClientIntegrationTest.java#L1077) 写真 写真 例えば、ここでコンシューマーがサブスクリプションを2回キャンセルすると、例外がスローされます。この時点で、ソースコード内で例外に基づいて接続状態を判断する条件を見つけることができます。 これは、クライアントが登録解除すると接続状態が変更されることを示しています。 ヘルツビート当時私がどのようにユニット テストに貢献したかを確認するために、Apache HertzBeat を例に挙げてみましょう。 写真 公式のアーキテクチャ図によると、HertzBeat はコレクターを使用してターゲットに直接接続し、データを収集します。 たとえば、Redis クライアントを使用して監視データを取得し、それを独自の時系列データベースに保存して表示することができます。 したがって、このデータ収集プロセスはコアロジックであり、そのインターフェース定義を見ることができます。 写真 インターフェースは全部で 3 つだけです。
写真 次に、異なるメトリックを収集するために、異なる実装クラスが割り当てられます。 ここではRedisCommonCollectImplを例に挙げます。メインのユニットテストロジックは、Redisクライアントの戻りデータをシミュレートし、Collectコード内の異なる処理ロジックを確認することです。実際には、様々な分岐や例外状況をカバーすることを目的としています。 最後に、収集されたデータが期待値と一致するかどうかをアサートします。コアロジックの抜粋を以下に示します。 写真 どのような結果が返されるべきかについては、一部のコレクターではコードコメントでこれを指定する場合があります。ただし、Redis では指定しません。 ただし、方法はあります。コードをローカルで実行し、管理コンソールにアクセスして組み込みの監視テンプレートを表示することができます。 写真 ここで監視するフィールドを定義するため、コード内で予想される戻り値を事前に生成できます。 写真 具体的な単体テスト コードは、次の場所にあります: https://github.com/apache/hertzbeat/blob/master/collector/src/test/java/org/apache/hertzbeat/collector/collect/redis/RedisClusterCollectImplTest.java#L46 要約確立されたオープンソース コミュニティに参加する際に覚えておくべきことの 1 つは、貢献者向けドキュメントを注意深く読むことです。 多くの場合、コードのビルド方法、コードスタイルガイドライン、コミットガイドラインが明確に説明されています。これらが明確化されると、提出されたPRがコミュニティに受け入れられる可能性が高まります。 統合テストとe2eテストに関するコンテンツは今後も更新していきます。 |
