architecture - 基于插件的架构有哪些优缺点？

Question

我想做一个软件的架构设计，可以在一个平台下集成各种第三方软件(可执行文件)。

默认情况下，标准项目类型将添加到平台中。项目类型定义了不同软件的执行方式及其输入和输出文件。

用户可以自定义可用的标准项目类型，并将其作为定义新自定义执行流程的新项目类型添加到平台。

它还应该支持功能的轻松扩展和定制。我读到基于插件的架构支持两者。

基于插件的架构有哪些优缺点？我们有没有更好的架构可以用于这种场景？

提前致谢:)

Answer 1

可插拔系统的好处是

可扩展性:应用程序可以动态扩展以包含新功能。

并行开发:由于功能可以作为单独的组件实现，它们可以由不同的团队并行开发。

明确的开发方向:由于插件框架理想地为插件编写者提供了定义良好的接口(interface)和文档，因此开发人员有一个明确的开发路线图。

简单:一个插件通常只有一个功能，因此开发人员只有一个关注点

但其中一些优势也是劣势:

可扩展性:插件接口(interface)是否预期插件编写者扩展应用程序的方式，或者它是否限制扩展。设计满足所有用例的可扩展性通常需要多次迭代或非常好的需求分析。

可维护性:插件框架的提供者不仅要确保插件接口(interface)满足缩进的用例、清晰且有据可查，还要确保它可以进化。管理与现有插件的版本和向后兼容性可能非常困难。足够难以至于许多实际的实现都不会打扰，并插入插件编写者使用每个版本更新他们的插件的责任。

复杂性:虽然每个插件在单独测试时都可以工作，但插件之间的交互可能会导致新问题，只有某些插件组合才会出现错误。

测试:如果插件系统不提供某种形式的模拟插件运行器进行测试，测试插件可能会很困难，这有时是不可能的，并且测试只能通过实际运行插件来进行，这会减慢开发速度。

人工分离:一个插件通常有一个焦点，但是什么构成一个焦点是由插件 api 提供者设置的。如果插件编写者发现他需要一个可以合理地同时完成两件事(由插件 api 定义)的插件，他可能最终不得不实现两个插件并找到提供它们之间的通信的方法，而这目前还没有由api。然后他不得不解决或反对插件框架。

设计一个好的插件环境与设计一个好的库有许多相同的挑战。如果您自己制作环境和插件，那还不错，因为您可以随着环境的发展更新所有插件，但是如果插件 api 对所有人开放，则需要仔细规划和执行才能获得设计随着环境的发展，避免过多的插件重写的权利。

Fred Brooks 描述的“ Second-system syndrome”主张开发的第二个系统通常过于通用，旨在实现最大的灵 active ，有时会产生“平台中的平台”/“ inner platform effect”。当需求不存在或未指定时，可插拔设计通常被视为一种出路。作为补偿，该软件尽可能灵活地尝试处理“发生的任何事情”。

如果这描绘了一幅沉闷的画面，那就请原谅 - 可插拔系统可能很棒并且提供了很多优势，但它们的价格很高。在深入研究可插拔系统之前，为您需要涵盖所需功能的所有插件制定要求是谨慎的。然后，这将帮助您确定可插拔设计是否值得努力，或者一些更简单的方法也同样适用。