想象一下构建您的软件就像从宜家订购家具一样。您挑选一张桌子，添加一个角件，将其抬高成为站立式办公桌，并添加一些腿部道具，并添加诸如组织者之类的小东西以更好地适应您的工作方式。事物是模块化的，您可以添加和删除点点滴滴来构建满足客户需求的项目。
在软件项目中，这通常是通过配置标志完成的，该标志位于服务器上的系统配置文件或数据库中。此标志控制功能中所有事物的可见性，并且可以根据需要打开和关闭。在最坏的情况下，您可能 必须在两者之间重新启动 apache 。另一种构建组件的方法是通过一 组 API 。程序员创建前端，然后混合和匹配已经存在的 API 来创建后端。
大型软件公司每天都使用组件来为客户创造体验。例如，Amazon.com 主页实际上是拉入单个逻辑框架的组件集合。 Google 将其可以搜索网络的 MapReduce 算法作为一项服务提供给所有员工。结合 MapReduce 和街道地址到纬度经度的转换 API，Google 地图突然间不仅可以通知您最快的路线，还可以通知您沿途有哪些餐馆、酒店和加油站。
使用组件构建不仅仅是一种更强大的软件架构方法；它还加快了整个软件交付过程。
更快的发布，无需在开发人员和测试人员之间来回走动
在许多版本中，功能或修复通常是在最后一刻添加的，这可能意味着在允许将代码部署到生产环境之前进行最后的全系统检查。这也意味着之前的任何测试都是在没有最后一块的情况下完成的，这会带来自身的风险。这在很大程度上是由于功能在实施过程的后期才到达测试组，或者是测试人员和致力于修复错误的开发人员之间的大量来回变动。如果该功能是作为组件构建的，可以添加或 减少的风险有限 ，团队可以为落后的部分关闭功能标志，然后继续发布已完成的部分。
更快地发布软件意味着您可以更快地为客户提供价值。这也意味着，通过灵活的发布时间表，您可以避免经典的发布死亡行军，在这种情况下，团队需要花费数周或数月的时间来发现并修复错误，然后才能推出产品。
加快发布速度的另一件重要事情是，如果确实出现严重错误，您可以关闭有问题的功能，而不是处理回滚和数据库版本控制。在客户根本无法做任何事情的压力下对生产进行修补程序通常会导致更多的修补程序。
复杂端到端测试的策略
在组件架构中，总体策略通常从简单地测试以发现和修复潜在问题，转变为专注于后期检测并在问题确实发生时减少暴露。通常会有多层程序检查，以确认程序在单元级别或 API 级别 以及可能在 UI 中执行开发人员认为应该执行的操作。但是，真正的测试很少发生。
这种策略在某些情况下有时会奏效，尤其是当软件是免费的并且主要用户实际上正在创建供其他人购买的数据时。 Facebook、Twitter 以及某种程度上的 GitHub 就是这种情况。
由于应该已经很好地覆盖了较低级别的功能，因此可以在测试端到端场景中找到最大的价值。虽然程序检查每次运行时都会查看相同的代码位，并且通常会查看非常简单的问题，但由人员执行的端到端测试可以探索用户可能实际执行的更复杂和更多样的可能性。
端到端测试可以帮助发现 黑天鹅 ，即大多数程序检查无法发现的具有巨大影响的令人惊讶的问题。
使用组件架构减少生产前的测试需求
如果您的策略已从测试和问题发现转向降低问题的暴露量，那么监控将变得越来越重要。组件架构可以减少预发布测试的需要，但必须有一个应急计划以防出现问题。
想象一个场景，在网站上添加了一种新型的支付处理方式。该功能是在夜间发布的，但这里的夜间时间在其他地方是白天，而且该功能几乎立即被使用。不知何故，该团队错过了一个关键场景，当在某个版本的 FireFox 中使用时，浏览器挂起。如果您设置了监控，通知将开始飞来飞去，并且可以快速关闭该功能。
复制客户配置以检查软件质量
使用组件管理测试环境可能会很棘手。通常，会有源源不断的提交和部署到测试环境。在较大的公司中，这可能意味着数百人同时相互推动变更。毫不奇怪，这会导致一个完全崩溃的环境，几乎不可能发现哪个更改导致了哪个问题或哪个两个功能不能很好地协同工作。
在一个客户那里，我们有一种产品，几乎所有功能都可以打开或关闭。每个客户都希望产品配置略有不同。最初，我们的策略是让所有东西一直保持打开状态，但这会导致一些功能无法协同工作的问题。那里的发布时间表有点慢，所以我们能够复制关键的 客户配置进行测试 。
不断推动测试环境的组织可能会通过使用最新发布版本的一部分创建特殊环境来妥协。在这一点上，在生产中进行测试是陈词滥调，但有时它是唯一的选择。
为什么 - 以及如何 - 开始
您可能想要切换到基于组件的架构的原因有很多。您可能希望更快地从灾难中恢复，减少回归测试时间，或者消除代价高昂的强化和协调时间。如何开始定义一个单一的服务 - 只是一个 - 将可重用，以及该 API 的一个消费者。 API应该是新开发的。从头开始重写旧代码几乎没有意义，但新功能开发已经得到资助。一旦该 API 到位，组织就可以开始有关 API、签名和版本注册的对话。现在，从一个 API 开始，学习一些东西，看看测试策略如何变化。
结论
攀登是艰难的，但从山顶看到的景色是值得的。
基于组件的架构与单体架构完全相反。您得到的不是一个大的、通常危险的更改产品，而是一个可以添加和删除的拼图。这些部分有助于打造更安全的开发环境、新的测试方式，并有望带来更好的用户体验。
使用基于组件的架构对您的工作有何影响？我们很想听听您的故事。