原文：HowUIComponentArchitectureCanSolveOrganizationalProblems
作者：SteveArmstrong
翻译：lloog
译者注：在本文中，作者讨论了UI组件架构的概念，以及如何帮助你提高Web开发团队的速度和效率。
UI组件是一个非常困难的问题。只是选择一个UI框架或者在一些设计模拟上进行迭代，一切都会得到解决。对吗?
问题是，我们解决问题的大部分方法都来自于研究小项目。在小型项目中，我们可以使用一个样式表，或者在UI框架上迭代。
在一个使用大量的产品的大型组织中，这不会奏效。以下是可能出错的细节：
缺乏规划和架构
设计师为产品创建高保真的模型。
前端团队将设计实现到应用程序中。
应用程序大小的增长。
随着应用的发展，前端团队创建了一个库来“共享”代码。
浪费时间和停滞
产品需要对其中一个组件进行更改，但该组件现在在20-30页。
开发人员不愿做出改变，因为担心它会在其他地方“崩溃”。
由于团队拥有站点的不同部分，开发人员甚至不知道什么可能会中断。
瓶颈的产生是因为变化是高风险的。
不一致
现在产品负责人“A”她不喜欢一个选择框，所以她让设计师模拟出了一个她喜欢的新的选择框。
创建了一个新的一次性组件，它将被输入到代码库中，而不需要团队的其他成员对此进行了解。
现在有两个选择框。
选择框的更改不会在应用程序中传播。
现在，不仅存在瓶颈，还存在设计上的不一致。这一过程也缺乏团队的支持。
高风险/复杂性和条式代码
现在有人提交另一个设计请求。
全局样式表的尺寸越来越大，以至于掩盖任何其他样式。
该组件引用了一种基础样式，它将以一种不受欢迎的方式更新许多内容。
所以创建样式拼图，重要的是添加，现在…
认真的…开发人员已经开发结束了，设计师已经退出了，产品主人仍然在问为什么简单的改变是如此难以做到。
幸运的是，有非常聪明的人努力解决这些问题。那么我们如何解决呢？下面这是如何添加一些结构的清单：
步骤1：构建组件库
即使您的组件库引用了一组开源组件，也可以构建自己的库和版本。不仅如此，为库中的所有组件创建包装器。这样，如果您需要将某些东西交换出来，则不需要更改外部API。您只需要修改实现细节。
组件库应该是应用程序的核心。所有的应用程序都需要这个库。不要在您的应用程序中编写组件和“向后移植”，而是在前面的组件上工作。这将生成更好的代码和更有意义的应用程序。
组件库的另一个优点是所有开发人员可以隔离和观察更改。特别是如果您正在管理GitHub中的代码，并在在合并之前需要提取请求。
在一个单一的应用程序中，很容易将变更转移到一个导致不一致的功能分支上。有了一个组件库，人们就可以抵制牛仔编程。
步骤2：将您的整体前端拆分成较小的应用程序
如果您的应用程序有很多页面，那么您应该尝试将所有这些页面移动到它们自己的SPA(单个页面应用程序)中。这个系统的美妙之处就在于，当您对组件库进行更改时，您可以对所有应用程序进行渐进的更新。它使你不必去做“一个巨大的更新”。
这减少了开发人员对更改导致更多工作的担心。团队能够按照自己的进度管理更新。不需要有一个巨大的组织推动来更新一个按钮。
步骤3:使用CSS模块隔离组件设计
CSS模块允许有两种情况。第一，他们摆脱了全局类暴露的问题。这意味着当您为组件更新一个类时，您确切知道将会更新什么，因为样式的范围是相对于组件的。
第二个主要优势是，开发人员知道所有样式都在哪里。他们不必担心样式表会在一组普通的样式表上分散开来。
步骤4:使用交互样式指南作为用户体验、产品和工程之间的合同
任何组件库都应该能够发布交互式样式指南。对于开发人员、产品团队和设计人员来说，这是一个中间地带。它允许您隔离您的组件并独立地处理它们。你可以更快地工作，看到变化更快。最好的部分是，一旦您发布了更新，它将通过整个应用程序传播这些更改。
交互式样式指南就像是故事书。它不仅捕获了外观和感觉，还公开了响应组件的状态(在工作中对Vue支持)。
既然您已经知道了所有组件的位置，就不需要每次都交付高保真的模型了。设计师可以更多地