0

我们正在努力在所有项目中标准化我们的 Bugzilla 应用程序。默认安装将错误分组到具有Components和Versions的Products中。

我们对Product和Version的定义是一致的，但是对于什么构成Component仍然存在一些混淆/讨论/争论。

您如何定义与项目中的错误分类相关的组件？

4

7 回答 7

4

出于错误跟踪的目的，我将使用 Component 来表示不同开发人员倾向于处理的高级区域。对我来说，Component [in bug tracking] == Area of​​ Concern。

例如，对于一个虚构的 EventPlanner 应用程序，我会将我的组件列出为：

  • 日历
  • 用户界面
  • 印刷

请注意，这可能与我作为开发人员通常认为的软件组件不同。例如，我的 EventPlanner 应用程序可能使用了日历 API，但“用户界面”和“打印”本身并不是软件组件。

于 2009-01-13T18:52:51.767 回答
2

组件是产品的细分，它提供产品功能的子集。

例如，如果 Stack Overflow 是产品，这里有一些潜在的组件：

  • 问题
  • 标签
  • 徽章
  • 简介

一些粘合逻辑应该将组件组合在一起以形成项目。

于 2009-01-13T18:48:06.127 回答
1

我会定义类似于引用代码分支的组件，例如 Visual Studio 中的项目，它可以是类库、控制台应用程序、Windows 应用程序或网站/Web 应用程序。

于 2009-01-13T18:18:41.630 回答
1

一个很好的定义，将服务于您的目的。

于 2009-01-13T18:30:23.637 回答
0

任何作为“帮助”对象的东西，做一些小事以支持应用程序的更大功能的东西，并且可以在其他 Products 中重用。

例如，一个 EmailSender 类，或者一个 ErrorLogger 等。

于 2009-01-13T18:20:02.393 回答
0

无论您最感兴趣的是什么，都将您的产品分解为错误跟踪。根据某些并非特定于错误跟踪问题的概念，区分对您有用而不是“正确”更重要。

对我来说，您可以在不破坏其他部分的情况下更改实现的任何代码部分都可以称为组件。您可以明确指出并说：“这个错误就在那里，而其他地方都没有。”

如果您的产品是一个巨大的意大利面条代码球，您可能无法从组件中获得任何好处。如果你已经很好地解耦了，并且你有一个非常大的项目，你可能有数百个可以称为“组件”的东西，你可能必须对它们进行语义分组以防止区分比它更麻烦值得。

编辑：为了回应对另一个答案的评论，如果提交错误的人对问题有必要的知识来进行归档，则此模型效果最佳。我们总是审查（分类）报告的错误并自己归档。如果您将组件选择留给用户，那么这个想法对您来说效果不佳。

于 2009-01-13T18:29:01.423 回答
0

伯克利大学的 A. Richard Newton 博士教授一门名为“基于组件的软件最新技术和经验教训”的课程，他将软件组件定义为

软件组件是仅具有合同规定的接口和明确的上下文依赖关系的组合单元。软件组件可以独立部署，并由第三方组成

我认为没有更好的定义。所以这里的错误可能在组件级别或接口级别，即组合级别。

于 2009-01-13T18:46:36.160 回答