您对软件产品中“组件”的定义是什么？

Question

我们正致力于在所有项目中标准化我们的Bugzilla应用程序。默认安装包含分为产品的错误，其中包含组件和版本。

我们对产品和版本的定义是统一的，但对于构​​成组件的内容仍然存在一些混淆/讨论/争论。

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

Answer 1

为了进行错误跟踪，我会使用Component来表示不同开发人员倾向于处理的高级区域。对我来说，组件[在错误跟踪中] ==关注区域。

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

• 日历
• 用户界面
• 打印

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

Answer 2

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

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

• 问题
• 标签
• 徽章
• 配置文件

一些胶水逻辑应该将组件拼凑在一起形成项目。

Answer 3

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

Answer 4

符合您目的的good definition。

Answer 5

任何“辅助”对象，可以做一些小事来支持应用程序的更大功能，可以在其他产品中重复使用。

例如，EmailSender类或ErrorLogger等

Answer 6

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

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

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

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

Answer 7

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

  

软件组件是一个单元   合同的组成   指定的接口和显式   仅限上下文依赖项。一个软件   组件可以部署   独立并受制于   由第三方组成

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