0

すべてのプロジェクトでBugzillaアプリケーションの標準化に取り組んでいます。デフォルトのインストールでは、コンポーネントとバージョンを持つ製品にバグがグループ化されています。

私たちは製品とバージョンの定義で団結していますが、コンポーネントを構成するものについてはまだ混乱/議論/議論があります。

プロジェクトのバグの分類に関連する限り、コンポーネントをどのように定義しますか？

4

7 に答える 7

4

For bug tracking purposes, I would use Component to represent high-level areas that different developers tend to handle. For me, Component [in bug tracking] == Area of Concern.

For example, for a fictional EventPlanner application, I would list my components as:

  • Calendar
  • User Interface
  • Printing

Note that this may be different than what I, as a developer, would typically consider a software component. For example, my EventPlanner app might have use Calendar API, but "User Interface" and "Printing" themselves are not software components.

于 2009-01-13T18:52:51.767 に答える
2

A component is a subdivision of a product and it provides a subset of the functionality of the product.

For example, if Stack Overflow is the product here are some potential components:

  • Questions
  • Tags
  • Badges
  • Profiles

A bit of glue logic should piece the components together to form the project.

于 2009-01-13T18:48:06.127 に答える
1

クラス ライブラリ、コンソール アプリケーション、Windows アプリケーション、または Web サイト/Web アプリケーションである Visual Studio 内のプロジェクトのようなコードのブランチを参照するのと同じように、Component を定義します。

于 2009-01-13T18:18:41.630 に答える
1

あなたの目的に役立つ良い定義。

于 2009-01-13T18:30:23.637 に答える
0

Dr. A. Richard Newton from the University of Berkeley who teaches a course called "Component-Based SoftwareState-of-the-Art and Lessons Learned" defines a software component as

A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties

I dont think there is a better definition. So bug here could be at component level or at interface level i.e. composition level.

于 2009-01-13T18:46:36.160 に答える
0

「ヘルパー」オブジェクトであり、アプリケーションのより大きな機能をサポートするために小さなことを行い、他の Products で再利用できるもの。

たとえば、EmailSender クラスや ErrorLogger などです。

于 2009-01-13T18:20:02.393 に答える
0

バグ追跡の目的で製品を分解することに最も関心があるものは何でも。バグ追跡の問題に固有ではないいくつかの概念に従って、区別が「正しい」ことよりも、区別が役立つことの方が重要です。

私にとって、他の部分を壊さずに実装を変更できるコードの部分は、コンポーネントとしての資格を得ることができます。「このバグはそこにあり、他にはありません」と明確に指摘できるもの。

製品が巨大なスパゲッティ コード ボールである場合、コンポーネントからは何のメリットも得られない可能性があります。非常にうまく分離し、非常に大規模なプロジェクトを持っている場合、「コンポーネント」と見なすことができるものが何百もある可能性があり、おそらくそれらを意味的にグループ化して、区別がそれ以上の問題にならないようにする必要があります。価値。

編集:別の回答に対するコメントに応じて、このモデルは、バグを報告する人が報告を行うために必要な問題の知識を持っている場合に最適に機能します。私たちは常に報告されたバグをレビュー (トリアージ) し、自分でファイルします。コンポーネントの選択をユーザーに任せている場合、この考えはうまく機能しません。

于 2009-01-13T18:29:01.423 に答える