c# - コード再利用ライブラリを作成および維持するにはどうすればよいですか?

Question

再利用可能なコードのリポジトリをセットアップしようとしています。私は、再利用可能な各コードモジュールに特定の「成熟度」の評価を持たせることを考えていました。評価は、再利用可能なコードが特定の一連の要件内にあるレベルとして定義されます。最高の成熟度レベルは、事前定義された一連の要件全体で最高度の標準になります。

例:
レベル。要件; 説明
レベル 0。コードの使用は合法です。コードは商業産業/複数の契約/その他での使用が合法ですか?
レベル1; 基本コードラインであり、レベル 0 の要件を満たしています。プロトタイプコード、サードパーティツールなど
レベル 2; 関数インターフェイスとコメントがあり、レベル 1 の要件を満たしています。各クラスと関数の十分なドキュメント。コメントから機能を判断できる
レベル 3; コーディング標準に準拠し、レベル 2 の要件を満たしています。定義されたコーディング標準に従い、コードチェックユーティリティテスト
レベル 4 に合格。テストケースを含み、レベル 3 の要件を満たしています。コードのすべての機能をテストするのに十分なテストケースがある
レベル 5; 再利用委員会によって承認され、レベル 4 の要件を満たしています。再利用の専門家や同業者によってレビューされ、すべてのレベルの成熟度を満たしていることが検証されました

この成熟度レベルを階層構造にする必要があるかどうか疑問に思っています。次のレベルに移動するには、前のすべてのレベルの要件を満たす必要があります (上で示したように)。

それとも、次のレベルを満たすための要件のサブセットである必要がありますか?

たとえば、y 個の要件のうち x 個を満たしている場合、次のレベルに進むことができます (要件は上記と同じです)。

レベル 0、6 つの要件のうち 0 つを満たす
レベル 1、6 つの要件のうち 1 つを満たす
…

サブセットアプローチで見られる問題は、一部の要件にはより強い重み付けが必要であり、このアプローチでは考慮されないことです (特定のようなものを取得し始めない限り、b から a と y から x を満たしているなど)。しかし、その後、複雑になり始める可能性があります。

誰かが以前にこれを行ったことがありますか?もしそうなら、どのようにライブラリをセットアップしましたか? 成熟度レベルはまったくありますか、それとも他の構造ですか? 任意の入力をいただければ幸いです。

score 9 · Accepted Answer

コード再利用リポジトリの設定は難しい作業です。主な問題は、それをどのようにセットアップするかではなく、リポジトリー内のさまざまなライブラリーの存在をどのように伝えるかです。ライブラリの再利用は、使用される場合にのみ有効であり、既知の場合にのみ使用され、コードの品質が高く、ユーザーのニーズを満たしている場合にのみ広く使用されます。

私は成熟度レベルの考え方が好きですが、他の人が投稿したように、おそらくかなりのセットアップ/ビルド作業が必要です. 私は、アプリケーションのビルドに対する同様のアプローチを考えました - 私はそれらを信頼レベルと呼びました。アプリケーションビルドの分野では、信頼度の低いビルドは単体テストに合格しなかったビルドです。信頼度が中程度の場合、単体テストには合格するが、統合テストには合格しない、などがあります。これは、QA とユーザーに何を期待するかを伝えるための優れたメカニズムでした。ライブラリにも同様のメカニズムが適している場合があります。

ドキュメントコメントは必須であり、コードに入れるのと同じくらい注意を払う必要があります。コメントは、何を、なぜ、どこで、いつ、どのように、どれなどを伝える必要があります。ビルドプロセスでは、ドキュメントを既知の場所に公開する必要があります (ここでも、コミュニケーションが重要です)。

コミュニケーションの線に沿って、そこにあるものだけを時々提示することは害にはなりません。また！コミュニケーション。

したがって、少なくとも各ライブラリのビルドは次のようにする必要があります。

ライブラリを公開する (おそらくサブスクライバーに通知する)
ドキュメントを公開する
単体テストを実行する
成熟度を公開する

成熟度については、「レベル名」とそのレベルの意味の説明で定義します。レベルを上げたり下げたりすることが何を意味するかについての基準を公開します。実際、考えてみると、コードのレベル、ドキュメントのレベル、使用ポリシー (つまり、XYZ のライセンスが必要)、およびその他の属性など、直交する一連の基準が必要になる場合があります。ただし、これには少しずつアプローチすることをお勧めします。結局のところ、エンドユーザーに機能を提供することが重要です。

また、再利用可能なビットをリポジトリに自然にプッシュするという考え方を伝える必要もあります。開発者は通常、これを行うインセンティブを持たなければなりません。重複やピアレビューを探す静的コードチェックツールは、これまでのところしか機能しません。コードをリポジトリに移動する作業は、誰かが実際に行う必要があります。

最後に、リポジトリのセットアップ、ビルド、メンテナンス、および通信において、できるだけ多くのツールサポートを使用することをお勧めします。そうしないと、コード以外のアーティファクトと同様に、コード以外のアーティファクトが古くなるにつれて値が低下する一定量のエントロピーに直面することになります。

score 5 · Accepted Answer

開発チーム全体がこれらのガイドラインに十分正確に従うようにするのは難しいと思います。特に、ガイドラインが何らかの方法で解釈される可能性がある場合. さらに、誰かがテストを追加してコードを改善し、突然別のプロジェクトに移動しなければならなくなった場合、それは大きな苦痛になります。ほとんどの場合、そのようなコードは最初に配置されたプロジェクトにとどまり、時間の経過とともに成熟度レベルが無意味になります。

私が大企業でうまく機能しているのを見た 1 つのアプローチは次のとおりです。

すべてのサードパーティライブラリは、特別なディレクトリにコミットされており、常にバージョン番号が含まれています。
私たち自身の共通ライブラリは、他のものへの参照に基づいて分割されています。たとえば、ユーティリティコードがInfragisticsライブラリを参照する場合、このユーティリティコードのビットはInfragisticsUtilsライブラリに入ります。
明確に識別可能な「ユニット」を形成する独自の共通ライブラリは、個別のライブラリに移動します。たとえば、証券の価格設定を扱うコードのライブラリは別のプロジェクトです。
上記のいずれも満たさないすべての再利用可能なコードは、キャッチオールUtilitiesプロジェクトに入ります。
私たち自身のライブラリはコンパイルされ、プロジェクトがそれらを参照できる共有の場所にリリースされます。コンパイルされたバイナリを参照するか、単にユーティリティプロジェクトをソリューションに含めるかを決定するのは、プロジェクトの開発チーム次第です。

Utilities明らかに、キャッチオールライブラリで見つけたコードの品質は大きく異なる可能性があります。これを軽減するために、異なる開発チームの 2 人がへのすべてのチェックインを確認するようにしましたUtilities。これにより、そこにない多くのものを取り除くことができます!

score 3 · Accepted Answer

優れたコードリポジトリには、CMツールとWikiツールが含まれていると思います。CMツールは、品質によってコードを構造化するため、（提案したように）レベルのアイデアを使用して構造化する必要があります。ウィキは、ソフトウェアが何をすることができ、それがどのようにあなたを助けることができるかについての「広告」として機能するべきです。このウィキには、コードを使用しているプロジェクト、コードの使用可能性の評価、使用方法の例などの情報を保持することもできます。レベルのガイドラインに従っている開発チームについて心配している人がいる場合は、セルフポリシングがどのように機能するかを指摘し、ウィキでどのように機能するかの例を示す必要があります。

ここで、CMツールの構造化が重要です。コードの品質を伝えるように設計されているので、使用するときに何に入るのかがわかります。たとえば、コメントがほとんどない単純なクラスを作成し、それがコーディング標準（おそらくプロトタイプ）に実際に準拠していない場合、それは\ sw_repository \ level0\ExamplePrototypeに入力されます。

たぶん、誰かがそのコードを受け取り、コメントを追加して、それを標準に引き上げます。次に、その人はそれを\ sw_repository \ level1\ExamplePrototypeに配置します。

次に、その同じ人が、しばらくして、ExamplePrototypeの単体テストを作成します。その後、これはレベル2などに進みます。

レベルの定義には、いくつかの考慮が必要です。それらは実際にはある程度シーケンシャルである必要があり、たとえば、プロトタイプコードの単体テストを作成したが、コメントとコーディング標準を満たしていない場合でも、とにかくレベル0に配置されます。ただし、これらのコメントと基準が満たされていれば、レベル2に進むのは簡単です。

score 2 · Accepted Answer

キットは、最も重要な問題である再利用について言及しました。アイデアの残りの部分は素晴らしいですが、それは詳細に過ぎません。

つまり、私自身、独自の再利用ライブラリを維持するのに苦労しています。時々、私は非常にプロジェクト固有の実装を行ったり、何らかのアイデアのために n 番目のプロトタイプを作成したりしますが、それらのどれもが私のライブラリに入ることがありません。

多くの開発者によって規律ある方法で使用および保守されているコード再利用ライブラリの作成に本当に成功した場合、それは勝利ではありません。バージョン管理システムとバグトラッカーが必要です。バグトラッカーはプロジェクトオーナーとユーザーの両方が使用します。コミュニケーションと貢献の手段が必要です。プロジェクトを使用する少数の開発者を持つことで、その品質が劇的に向上します。実装が良くなります。ドキュメンテーションが作成されます。API と機能の設計は、はるかに高いレベルにあります。委員会は素晴らしいものですが、与えられたコードがどれほど優れているかは、実際に使用しないと判断できません。コードが特定の基準を満たしているかどうかを判断することはできますが、基準を満たすだけでは優れたライブラリには不十分です。

確認するために最善を尽くす必要があります。大量のコードスニペットが浮かんでいないことを確認する必要があります。わかりました。設計上の決定には長所と短所がありますが、特定のタスクに対して 1 つのプロジェクトから開始し、本当に必要な場合はそれを分岐し、プロジェクトチーム間のコミュニケーションを維持し、(部分的に) マージを検討する方が理にかなっていると思います。戻る。

さまざまなプロジェクトの品質を分類することについてあまり心配する必要はありません。プロジェクトが悪い場合、ユーザー/開発者はそれをより良いレベルに押し上げます。ほとんどの人は、図書館が良い時とそうでない時を見分けるのに十分賢いです。厳しいルールで参加者に負担をかけようとするのではなく、これらの共生効果にエネルギーを注ぐ必要があります.

ちょうど私の2セント... ;)

score 2 · Accepted Answer

私のライブラリには、複数のアプリケーションで使用できるコードを記述しただけです。コードが特定のアプリに固有のものである場合、そのコードはライブラリには入りません。より多くのアプリがそれを使用するにつれて、バグが解決されるので、すぐにバグがなくなるとは思っていません. ライブラリが成熟し、さまざまなアプリでストレスがかかるにつれて、バグは常に発見され、修正されます。バグがなくなることはありませんが、時間の経過とともに信頼性に近づきます。また、一部の API が間違っていることに気付いた場合は、それを気にせず、できるだけ早く API をリファクタリングします。

これが私のC ++のライブラリです
http://code.google.com/p/kgui/

score 2 · Accepted Answer

何年もの間、Microsoft はソフトウェアファクトリとして知られるものを強く支持してきました。その大部分は、再利用の問題の解決に向けられています。

リユースの問題点は？まず大変です。現在のプロジェクトの差し迫ったニーズを超えて機能するライブラリと API を考え出すのは非常に困難です。未来をどのように予測しますか？また、ナレッジベースと活発な実践コミュニティの両方として機能する中央リポジトリの問題は、非常に困難です。非常に柔軟でありながら使いやすいものをどのように作成しますか? 多くの人が試みて失敗しました。ソフトウェアファクトリとソフトウェア製品ラインの両方が、これらの問題に対処しようとしています。

幸運を！

score 1 · Accepted Answer

Will Tracz の「Confessions of a Used Program Salesman」と、HP の再利用ラビ、Martin Griss によるものを見てください。

score 0 · Accepted Answer

問題ないのに考えすぎだと思います。

ライブラリをどのようにセットアップしましたか? 簡単です。2 つ以上のプロジェクトで同じ (またはほとんど同じ) メソッドを使用している場合は、ライブラリに移動します。

score -1 · Accepted Answer

独自のライブラリを持つことは良いアプローチと考えられていますが、数千行のライブラリは廃墟です !

c# - コード再利用ライブラリを作成および維持するにはどうすればよいですか?

9 に答える 9

Related

Reference