オープンソースプロジェクト：Media Player ClassicおよびSharpDevelop。 第一印象

開発の世界では想像を絶する何かが起こっています。人気のあるプログラム、基本的なライブラリがオープンソースでレイアウトされています。 通常の開発者には、有名な製品に変更を加える機会があります。 だから、私は毎日のルーチンにうんざりして、新しいことを試して、創造的な思考の飛行を感じて、素晴らしいものに参加することにしました。 簡単に言えば、私はいくつかのオープンソースプロジェクトに接続することにしました。



なぜオープンソースなのですか？ 私が惹かれているのは：

• 厳密な開発期限がない
• タスクの自由な選択
• タスクを達成する方法の自由な選択
• 人気のある製品に変更を加える機能

この記事では、2つのプロジェクト（Media Player Classic-Home CinemaとSharpDevelop）での最初の経験について説明します。 初期段階でのオープンソースプロジェクトでの作業に関する一般的な推奨事項を述べたいと思います。 この記事には、ソースコードの本格的な分析や新しい機能の宣伝は含まれていません。プロジェクトでの作業の第一印象についてのみ説明しています。 おそらくこの記事は、開発者の注意をそれに記載されているプロジェクトと、一般的なオープンソース開発に向けるでしょう。

Media Player Classic-ホームシネマ

まず、Windows用のオーディオおよびビデオファイル用の無料プレーヤーであるMedia Player Classic-Home Cinema（MPC-HC）に興味を持ちました。 私は今でもプレイヤーを最速かつ最も便利なプレイヤーの一人と考えています。 プログラムはC ++で記述されており、インターフェイスはMFCライブラリを使用して開発されています。



プログラムのソースコードはgithubにあり、アクティブなタスクのリストは、Trackシステムの制御下にある別のバグトラッカーで維持されます。 さらに、IRCチャンネルで開発チームとリアルタイムでチャットできます。 これを行うには、ほとんどの開発者がヨーロッパ諸国（ドイツ、フランス、オランダなど）にいるため、時間を考慮する必要があります。



ソースコード： github.com/mpc-hc/mpc-hc

タスクトラッカー： trac.mpc-hc.org

IRC開発者チャット： webchat.freenode.net/?randomnick=1&channels=mpc-hc-dev&prompt=1&uio=d4

公式ウェブサイト： mpc-hc.org



タスクのリストを確認した後、タスク＃4328を選択しました。メインプログラムパネルに障害を持つ人々のために閉じるボタンを追加する必要がありました。 数時間を費やした後、新しいボタンを追加し、プログラムをチェックしてプルリクエストを作成しました。



プルリクエストへのコメントで、開発者はそのようなボタンは不要であると書いています。 そのようなタスクがトラッカーでハングする理由を尋ねられたとき、彼らは、時間の不足のためにチームが見なかったトラッカーにハングしている膨大な数のタスクがあると答えました。 次に、コメントの中で、プレーヤーに追加できるものについて議論が始まりました。フルスクリーンモードを終了するボタン、またはスクロールバーのプレビューウィンドウ（Youtubeプレーヤー）です。 残念ながら、議論では具体的な結果は得られませんでした。



私が理解しているように、プロジェクトにはタスクを積極的に開発している開発者のバックボーンがあります。 トラッカーでハングするタスクのほとんどは古くなっています。 基本的に、これらはユーザーからの機能要求です。 開発者は、新しい参加者がどのようなタスクを達成できるかという質問に答える準備ができていませんが、プレーヤーに新しい機能を提案する場合、開発者はそれに対して議論をすることができます。 任意のタスクを自分で選択して実行できますが、タスクが関連し、変更がメインブランチに延期されるという保証はありません。 そのため、新しい参加者がプロジェクトに参加することは非常に困難です。



ちなみに、プログラムを閉じるための追加のボタンを備えたプレーヤーの単独バージョンはコンピューターに残りました。

シャープ開発

MPC-HCでの動作に失敗した後、私の意見は、.NETベースのプログラミング言語のオープン開発環境であるSharpDevelopに落ちました。 プロジェクトはC＃.NET 4.5で開発されました。 プログラムインターフェイスは、WPFとWinFormsを使用して開発されます。 Habréのプログラムの機能については、すでに多くのことが書かれています。繰り返しません。



製品のソースコードはgithubにあり、アクティブなタスクのリストがそこに保持されています。 別のフォーラムで開発者に手紙を書くことができます。答えは1〜2日以内に十分に早く届きます。 さらに、現在のプログラムバイナリまたはインストールパッケージをダウンロードできるビルドサーバーがあります。 組み立ては2〜3日間隔で行われます。



ソースコード： github.com/icsharpcode/SharpDevelop

フォーラム： community.sharpdevelop.net/forums

CIサーバー： build.sharpdevelop.net/BuildArtefacts

公式ウェブサイト： www.icsharpcode.net/OpenSource/SD



プロジェクトの構造は喜ばせざるを得ません。ソースコードは別々のコンポーネントに配布され、本格的なプラグインシステムが実装されます。



Subversionバージョン管理システムのサポートは、別個のSubversionAddIn.dllプラグインで実装され、Subversionでの作業はSharpSvnライブラリを使用して実行されます。 Gitサポートは別のモジュールGitAddIn.dllでも提供されますが、バージョン管理システムでの作業はgitコマンドラインを介して既に実行されています。



さまざまなプログラミング言語のサポートも、CppBinding.dll、CSharpBinding.dll、FSharpBinding.dll、VBBinding.dllなどの個別のプラグインで配布されます。



ソースコードを解析するためのロジックは、独立した本格的なNRefactoryプロジェクトで使用されます。 残念ながら、Roslynプロジェクトとは異なり、NRefactoryライブラリはILコードのコンパイルとVB.NETコードの解析を実装しません。



最初に、タスクのリストからエラー番号606を選択しました。 「構成エディター」ウィンドウ（構成設定ウィンドウおよびソリューションプラットフォーム）を閉じた後、選択したデバッグまたはリリース構成がソリューション全体に対してアクティブになりませんでした。 1行のコードでエラーを修正したら、プルリクエストを作成しました。 数日後、私の変更は開発者の一人によってプロジェクトのメインブランチに適用されました。



次に、＃96という番号のより興味深いタスクを選択しました。VisualStudioと同様に、AssemblyInfo.csファイルを編集するためのウィンドウを追加する必要がありました。 これで、SharpDevelopプロジェクトのプロパティに、アセンブリプロパティの入力フィールドを持つ新しいタブ「アセンブリ情報」が表示されました。 Visual Studioのダイアログボックスと比較して、いくつかのイノベーションがあります。新しいビルドGUIDを生成するための[新しいGUID]ボタンと、アセンブリのJIT最適化を有効/無効にする機能です。



上記のNRefactoryライブラリを使用して、AssemblyInfo.csファイルのソースコードを操作しました。

数日後、私の変更は追加のコメントなしでメイン製品ブランチに投稿されました。 新しいタブでコメントや提案を聞くと予想していたので、これは少し不安になりました。 誰もがプロジェクトを散らかすことができるのではないかと心配しています。機能を複製するか、プログラムのメインロジックとは異なるロジックを導入します。 そうでないことを望み、開発者の変更はまだ何らかの検証を受けています。



以下に、新しい「アセンブリ情報」タブのスクリーンショットを示します。このタブは、5.1.0.4954のベータ版で既に表示されています。

一般的な推奨事項

最後に、新しいオープンソース開発者向けの便利なヒント。

最初のタスク選択

プロジェクトに完全に取り組む前に、コア開発チームからの応答を確認する必要があります。 無駄に多くの時間を無駄にしないために、小さなタスクを選択する必要があります。 何よりも、変更が本当に必要であったことは間違いないので、これは新しい機能ではなくバグです。 新しい技術やプロジェクトの詳細を勉強するのに時間をかけすぎないように、あなたが最も精通している分野からタスクを選択することをお勧めします。

私の場合、プログラムのユーザーインターフェイスに関連するタスクを選択する方が適切でした。

開発チームが変更要求に迅速に対応していることが判明すると、より深刻で興味深いタスクを選択することが可能になります。

コード設計

C＃コードの設計のルールについて話す場合、それらは主にデフォルトのReSharper'a設定によって長らく指示されてきたものです。 しかし、さまざまなプロジェクトでは、何らかの理由で、時々小さな違いがあります。 それらのいくつかを次に示します。

• プライベートフィールドの登録：プレフィックス「_」またはプレフィックスなし
• 定数：UPPER_CASEまたはPascalスタイル
• namespace'aの宣言の前または後に使用する
• varの普及

コメント

希望する言語でコードにコメントを書くことを忘れないでください。 ほとんどの場合、選択するプロジェクトはさまざまな国の人々によって開発され、コメントは英語で行われます。

ライセンステキスト

必要に応じて、ライセンスファイルをコードファイルに追加します。 たとえば、バージョン5以降のSharpDevelopプロジェクトの場合、ソースファイルにはMITライセンスのテキストが含まれ、Media Player Classicプロジェクトの場合はGNU GPLライセンスのテキストが含まれます。

くぼみ

コードのインデントはプロジェクトによって異なる場合があります。MediaPlayer Classicの場合はスペース、SharpDevelopの場合はタブです。

プログラムの一般的なロジック

タスクで作業するときは、プログラムの一般的なロジックに注意してください。 たとえば、例外処理ロジックまたはユーザー入力検証ロジック。 独自のコードで例外をキャッチしてエラーメッセージを表示するのは理にかなっていますか、またはプログラムでグローバル例外ハンドラーが定義されていますか？ 誤って入力されたデータに関する警告をユーザーに与える方法 驚くべきことに、作業の論理はプログラムによって根本的に異なる場合があります。

プルリクエストを作成する前の検証

タスクを完了した後、プルリクエストを作成する前に、変更を慎重に確認することをお勧めします。

変更されたファイルのリスト

バージョン管理システムまたは組み込みの開発環境ツールを使用して、変更されたファイルのリストを確認する必要があります。 開発プロセス中にコードが誤って変更された可能性があります。おそらく、開発環境がファイルを独自に変更することを決定した可能性があります。

プロジェクトの組み立て

理想的なケースでは、フォークリポジトリからソリューションを含む別のフォルダーをダウンロードし、再度コンパイルする必要があります。 組み込みのgitサポートを備えたVisual Studioを使用すると、何度か失望させられました。変更されたファイルのリストに新しいソースファイルが追加されませんでした。 個別にダウンロードしたフォルダーからプロジェクトを収集することによってのみ、変更の正確性を検証することができました。

テストをビルドして実行する

テストは、別のプロジェクトまたはソリューションで行うことができます。 開発中にそれらについて簡単に忘れることができます。

プログラムはさまざまなオペレーティングシステムで実行されます

記述されたコードがサポートされているすべてのオペレーティングシステムで動作することを100％確信できない場合は、仮想マシンでプログラムの動作を確認することをお勧めします。



それだけです。 オープンソースプロジェクトを検索して作業した結果、新しい趣味を見つけることができただけでなく、自分自身のために新しいことを学ぶことができました。 次に、SharpDevelopプロジェクトでの作業を続けるか、Media Player Classicを「嵐に乗せて」と思います。 Roslyn、.NET Core、Entity Framework、および他の多くのプロジェクトが多数あるため、他のプロジェクトの方向を見ることも理にかなっている場合があります。