用户界面组件体系结构如何解决组织问题

　　UI组件是一个非常困难的问题。只是选择一个UI框架或者在一些设计模拟上进行迭代，一切都会得到解决。对吗？

　　问题是，我们解决问题的大部分方法都来自于研究小项目。在小型项目中，我们可以使用一个样式表，或者在UI框架上迭代。

　　在一个使用大量的产品的大型组织中，这不会奏效。 以下是可能出错的细节：

　　缺乏规划和架构

　　设计师为产品创建高保真的模型。

　　前端团队将设计实现到应用程序中。

　　应用程序大小的增长。

　　随着应用的发展，前端团队创建了一个库来“共享”代码。

　　浪费时间和停滞

　　产品需要对其中一个组件进行更改，但该组件现在在20-30页。

　　开发人员不愿做出改变，因为担心它会在其他地方“崩溃”。

　　由于团队拥有站点的不同部分，开发人员甚至不知道什么可能会中断。

　　瓶颈的产生是因为变化是高风险的。

　　不一致

　　现在产品负责人“A”她不喜欢一个选择框，所以她让设计师模拟出了一个她喜欢的新的选择框。

　　创建了一个新的一次性组件，它将被输入到代码库中，而不需要团队的其他成员对此进行了解。

　　现在有两个选择框。

　　选择框的更改不会在应用程序中传播。

　　现在，不仅存在瓶颈，还存在设计上的不一致。这一过程也缺乏团队的支持。

　　高风险/复杂性和条式代码

　　现在有人提交另一个设计请求。

　　全局样式表的尺寸越来越大，以至于掩盖任何其他样式。

　　该组件引用了一种基础样式，它将以一种不受欢迎的方式更新许多内容。

　　所以创建样式拼图，重要的是添加，现在…

　　认真的…开发人员已经开发结束了，设计师已经退出了，产品主人仍然在问为什么简单的改变是如此难以做到。

　　幸运的是，有非常聪明的人努力解决这些问题。 那么我们如何解决呢？ 下面这是如何添加一些结构的清单：

　　步骤1：构建组件库

　　即使您的组件库引用了一组开源组件，也可以构建自己的库和版本。不仅如此，为库中的所有组件创建包装器。这样，如果您需要将某些东西交换出来，则不需要更改外部API。您只需要修改实现细节。

　　组件库应该是应用程序的核心。所有的应用程序都需要这个库。不要在您的应用程序中编写组件和“向后移植”，而是在前面的组件上工作。这将生成更好的代码和更有意义的应用程序。

　　组件库的另一个优点是所有开发人员可以隔离和观察更改。特别是如果您正在管理GitHub中的代码，并在在合并之前需要提取请求。

　　在一个单一的应用程序中，很容易将变更转移到一个导致不一致的功能分支上。有了一个组件库，人们就可以抵制牛仔编程。

　　步骤2：将您的整体前端拆分成较小的应用程序

　　如果您的应用程序有很多页面，那么您应该尝试将所有这些页面移动到它们自己的SPA（单个页面应用程序）中。这个系统的美妙之处就在于，当您对组件库进行更改时，您可以对所有应用程序进行渐进的更新。它使你不必去做“一个巨大的更新”。

　　这减少了开发人员对更改导致更多工作的担心。团队能够按照自己的进度管理更新。不需要有一个巨大的组织推动来更新一个按钮。

　　步骤3：使用CSS模块隔离组件设计

　　CSS模块允许有两种情况。第一，他们摆脱了全局类暴露的问题。这意味着当您为组件更新一个类时，您确切知道将会更新什么，因为样式的范围是相对于组件的。

　　第二个主要优势是，开发人员知道所有样式都在哪里。他们不必担心样式表会在一组普通的样式表上分散开来。

　　步骤4：使用交互样式指南作为用户体验、产品和工程之间的合同

　　任何组件库都应该能够发布交互式样式指南。对于开发人员、产品团队和设计人员来说，这是一个中间地带。它允许您隔离您的组件并独立地处理它们。你可以更快地工作，看到变化更快。最好的部分是，一旦您发布了更新，它将通过整个应用程序传播这些更改。

　　交互式样式指南就像是故事书。它不仅捕获了外观和感觉，还公开了响应组件的状态（在工作中对Vue支持）。

　　既然您已经知道了所有组件的位置，就不需要每次都交付高保真的模型了。设计师可以更多地关注行为、信息设计和用户体验。开发人员在开始新功能时不必担心设计问题。他们可以专注于业务逻辑和复杂的行为。

　　这种方法的潜在流程如下：

　　一个特性请求通过并被分解成一组组件。

　　前端开发人员决定该特性是否需要新的组件或更改。

　　如果没有，那么特性开发就可以开始了。

　　如果需要新的特性，开发人员将在组件库中创建一个特性分支。在产品、UX和其他开发人员的交互式风格指南中，这些更改将被评审。

　　一旦更改或新组件被批准，该分支就被移动到主文件中。

　　根据更改的不同，这个库的新版本是在semver之后创建的。

　　将应用程序的设计抽象为一组组件，并开发成组件库。该库应使用NPM进行版本控制。打破API或可能的主要设计变更将保证主要版本的更改。

　　应用程序的部分被分解为具有自己的package.json的SPA（单页面应用程序）。这允许他们以可控的方式对组件进行升级。

　　新组件或更改在开始特性开发之前就已经确定了。产品、UX和工程可以使用交互式样式指南在组件设计上进行协作，并在站点上看到一个“真实”的副本。更改并不可怕，因为如果存在与更改相关的风险，开发人员可以使用版本控制来减轻影响。另外，现在使用CSS模块对组件样式进行隔离，因此对组件“a”的更改不会影响组件“b”。

　　用户体验现在可以交付低精度的模拟组件，根据名称来引用组件。开发人员知道要使用哪些组件，不需要在“共享”代码的某个地方“钓鱼”。

　　另一个设计？没有问题。我们将在组件库中创建一个分支，并更新所有样式。当我们准备发布时，我们将创建一个主要的版本更新。问题就解决了。

　　缺点呢？

　　将“整个应用”更新仍然会有支持者。

　　将应用程序拆分为小应用程序可能会对某些产品造成规模太大的问题。

　　预先设计组件需要满足团队中大量的规范。并不是每个人都能够抽象需求并据此制定计划。

　　牛仔编程仍然可以实现。你的库和你的程序需要一个所有者。

　　这不是一个容易的跳跃，它需要整个组织的支持。如果您的目标是在增加团队速度的同时减少瓶颈和草率的更新，那么上面罗列的就是您的方法。如果你仍然相信“推送”按钮的更新。祝你好运！当你看到速度下降和成本上升时不要感到惊讶。