后端开发教程 - Java、Spring Boot 实战 - msg200.com
组件驱动开发（CDD）指南
让组件驱动应用程序的开发。
自 20 世纪 60 年代以来，
模块化一直是软件开发的关键原则。它在软件开发中提供了许多优势，利用关注点分离实现了更好的可重用性、可组合性、开发性等。
在现代，模块化通过组件在软件应用程序的设计中呈现出一种新的形式。现代 UI 库和框架（例如React、Vue和Angular）以及面向 CDD 的工具（例如Bit）使我们能够通过模块化组件构建应用程序，从而提供单独开发每个组件并将它们组合在一起所需的模式和工具。
组件是我们应用 UI 中定义明确且独立的部分。聊天窗口、按钮、滑块都是组件。组件也可以由更小的组件和片段组成。每个组件都是一个构建块。
这种方法催生了一种名为CDD（组件驱动开发）的新型模块化形式。通过理解 CDD 及其使用方法，我们可以使用组件来驱动应用程序的开发，从而受益于这种新模块化带来的优势。
展望Web 组件的世界，CDD 将成为开发应用程序前端的标准化方法。
UI组件驱动开发
简而言之，组件驱动开发意味着通过构建松散耦合的独立组件来设计软件应用程序。每个组件都有一个接口与系统的其他部分进行通信，多个组件组合在一起形成一个模块化应用程序。
例如，在构建 React 应用程序时，这意味着首先构建组件作为应用程序的基础，然后向上移动以组成 UI 的更大部分，例如应用程序中的整个页面和功能。
CDD 方法与原子设计（参见：React 中的原子设计：简化复杂的 UI）和微前端等原则相关。
CDD 帮助您将开发工作拆分成多个组件。每个组件都独立于应用程序的其他部分进行设计，并可与其进行通信。将每个组件设计为独立单元会带来诸多优势。
Addy Osmani在他的FIRST 原则中列出了 CDD 的一些主要好处：
-
更快的开发速度：将开发拆分成多个组件，让您能够使用功能更集中的 API 构建模块化组件。这意味着您可以更快地构建每个组件，并在其达到一定水平后进行学习。
-
更简单的维护：当您需要修改或更新应用程序的某个部分时，您可以扩展或更新组件，而不必重构应用程序的大部分内容。这就像对特定器官进行手术，而不是对整个身体系统进行手术。
-
更好的可重用性：通过关注点分离，组件可以被重用和扩展以构建多个应用程序，而不必一遍又一遍地重写它们（参见：共享（组件）就是关怀）。
-
更好的测试驱动开发 (TDD )：构建模块化组件时，更容易实现单元测试，以验证每个组件的重点功能。大型系统更容易测试，因为更容易理解和分离系统各部分的职责。
-
更短的学习曲线：当开发人员必须深入研究一个新项目时，学习和理解定义组件的结构比深入研究整个应用程序要容易得多。
-
更好的系统建模：当系统由模块化组件组成时，它更容易掌握、理解和操作。
组件驱动开发工具
当组件驱动开发时，需要专用工具来开发、测试、共享和协作组件。
尤其重要的是，要独立开发和测试组件，以确保它们能够作为独立的单元在应用程序中运行。此外，确保组件的可重用性和可共享性也很重要，这样您就不必每次需要组件时都重新设计轮子。
以下是一些可以帮助您完成 CDD 工作流程的实用工具。下一节，我们将讨论推荐的 CDD 实施架构。
组件开发与协作：Bit
Bit是一款开源工具，主要为组件驱动开发而构建。它可以帮助您使用组件进行开发、协作和构建。
Bit 可用于虚拟隔离您正在应用程序或库中开发的组件。Bit 将组件及其所有文件和依赖项封装在一个 CLI 命令中，并允许您独立地开发和测试封装组件的虚拟表示。
这意味着在您的应用程序中编写的组件突然被捆绑、封装并准备在您的应用程序之外使用（和测试）。
然后，bit 允许您打包已捆绑和封装的组件并将其共享到云端。在那里，您的团队可以直观地探索和发现所有共享组件。社区拥有近 5 万名开发人员，您还可以找到其他人共享的数千个开源组件。
CDD：使用组件构建
通过组件云，您的团队可以在新应用程序中安装组件，甚至可以直接从使用这些组件的新项目中建议更新。Bit 扩展了 Git，可以跟踪和同步不同项目中组件源代码的更改，从而让您能够掌控更改和更新。
由于 Bit 定义了每个组件的完整依赖关系图，因此当您更新组件时，您可以准确地了解哪些依赖组件会受到影响，以及在进行更改时哪些组件可能会中断。这意味着您将获得全面的组件驱动开发体验，从开发到测试，再到跨应用程序和跨人员共享和协作。
通过云进行组件驱动开发
另一个有用的优势是，旅游团队不仅可以在一个地方探索所有组件，还可以做更多的事情：开发人员实际上可以使用他们找到的现成的组件，甚至建议更新。
设计师、产品人员和其他所有人在可视化的 Playground 视图中协作处理实际源代码时，都能达成共识。设计与开发之间的差距缩小了，每个人都能从中受益。尤其是您的用户，他们将减少遇到不一致和令人困惑的错误。
学习：
UI 组件浏览器：StoryBook 和 Styleguidist
Storybook 和 Styleguidist 是 React 中快速 UI 开发的环境。两者都是加速组件开发的绝佳工具。
以下是简短的概述。
StoryBook — 交互式 UI 组件开发与测试：React、React Native、Vue、Angular
（https://github.com/storybooks/storybook）
Storybook是一个 UI 组件的快速开发环境。
它允许您浏览组件库，查看每个组件的不同状态，并以交互方式开发和测试组件。
StoryBook 可帮助您独立于应用程序开发组件，这也有助于提高组件的可重用性和可测试性。
您可以浏览库中的组件，试用它们的属性，并立即体验 Web 上的热重载功能。您可以在这里找到一些常用的示例。
不同的插件可以帮助您加快开发过程，从而缩短从代码调整到可视化输出的周期。StoryBook 还支持React Native和Vue.js。
React Styleguidist是一个组件开发环境，具有热重载开发服务器和实时样式指南，其中列出了组件 propTypes 并显示基于 .md 文件的可编辑使用示例。
它支持 ES6、Flow 和 TypeScript，并可与 Create React App 开箱即用。自动生成的使用文档可以帮助 Styleguidist 成为您团队不同组件的可视化文档门户。
- 另请查看Formidable Labs 的**React Live **。
StoryBook 和 StyleGuidist 之间的区别
使用 Storybook，您可以在 JavaScript 文件中编写故事。使用 Styleguidist，您可以在 Markdown 文件中编写示例。Storybook 每次只能显示一个组件的变体，而 Styleguidist 可以显示不同组件的多个变体。Storybook 非常适合显示组件的状态，而 Styleguidist 则适用于不同组件的文档和演示。
组件驱动开发架构
CDD 意味着你首先要构建组件，并尽可能独立于应用程序的其他部分。这意味着你不仅要构建一组组件，还要实现一个UI 组件设计系统。
您可以将组件作为应用程序本身的一部分（即在同一个项目中）实现，也可以将其作为单独的存储库（即组件库）实现。像Bit这样的工具可以让你隔离和封装每个组件，以便无论组件在哪里编写，都可以在任何地方进行开发、测试、重用甚至更新。
在设计组件时，首先要确保它们可复用，以便构建不同的应用。因此，你应该了解如何让它们可复用。没有什么比花费 6 个月时间构建一个最终无人使用的库更糟糕的了。是的，很多团队都会遇到这种情况。
为什么要建图书馆？
事实是这样的。Git 仓库并非为项目间共享的原子组件而构建。包管理器也并非如此。它们都是为仓库而构建的。组件并非仓库。
这就是为什么当我们想把我们应用中的组件移植到另一个应用中时，必须创建一个新的仓库。为了节省开销，大多数团队会创建一个共享仓库来托管 20 到 30 个组件。
如果使用 Bit，您可能不需要库。您可以直接将应用程序中的组件共享到云端，然后将其安装在其他项目中。这有点像 CD 音乐专辑和 Spotify 之间的区别。不过，您也可以将 Bit 和 StoryBook 与共享库一起使用，所以不用担心。
在设计库时，你应该做出一些关键决策。一些关键原则将指导你完成这项工作，要点如下：你应该开发独立的组件。其余部分应该像乐高积木一样组合。否则，当有人第一次需要与库中定义的内容不同的东西时，事情就会遇到障碍。然后，他们就不会使用它。
假设您确实建了一个图书馆……这里有一些可靠的建议。
构建面向 CDD 的优秀 UI 库的 7 个关键
-
标准——你的库中的开发标准是什么？组件在哪里？测试在哪里？样式在哪里？你的技术栈是什么（比如，你会使用 TS 吗）？组件是如何划分的？“Table”是由“Row”和“Cell”组成的吗？“Tabs”是由“tab”组成的吗？等等……？你明白了。让设计师也参与到这个过程中非常重要，这样可以确保你的库足够灵活，能够满足他们未来的需求。
-
样式- 您将如何设置组件的样式？** **您会将 CSS 耦合到每个组件吗？如果是这样，当设计师只需要为不同的应用进行一些更改时会发生什么？或许，在 JS 库中使用 CSS可以更好地解耦它们？如果使用bit.dev，您可以将主题分离为独立的组件，这些组件可以与逻辑组件组合，这样您就可以在每个应用中编写正确的逻辑和样式。通过模块化实现最大的灵活性，是不是很棒？
-
测试- 您将如何测试库中的组件？Jest 和 Enzyme？在选择合适的框架+实用程序+工具组合之前，最好进行彻底检查，以确保测试不会妨碍工作，反而能提供有价值的数据来辅助您的持续开发 (CDD)。单元测试固然很好，但应该测试组件的功能 API，而不是实现细节。集成和端到端测试同样重要。Bit 使 TDD 成为 CDD 的驱动力。它允许您在应用程序环境之外即时捆绑、封装和测试组件，以验证它们的独立性。更新组件时，您还可以了解哪些依赖组件可能会因此中断。在云端，组件单元测试结果是可发现性的关键因素。
-
构建过程- 代码需要编译。如何定义库的构建过程？发布机制？直接复制粘贴应用的构建过程到库中（或许可行）？为每个组件（例如 Lerna）定义构建配置以便发布？使用 Bit 定义一个适用于所有（或部分）组件的编译器？如果把事情搞得太复杂，开发过程会变得痛苦，模块化会受到影响，PR 的学习曲线也会很烦人。
-
所有权——谁拥有这个库？大型组织通常拥有一个前端基础设施团队，有时还会有一位架构师。他们正在构建一种名为共享库的产品。组织内其他构建应用程序的前端团队则是消费者。因此，为他们创造可发现性（例如 Bit、StoryBook）就变得非常重要，让他们提出更新建议（例如 Bit）就更加重要。否则，消费开发者不会愿意将他们的应用程序与库耦合，并等待每个拉取请求的 PR（PR 可能会出现，也可能不会出现）。不要强制执行，要合作。如果你不这样做，人们就会直接复制粘贴代码，没有人会知道。这是你的错。如果你的团队规模较小，请明确负责人。即使没有人全职工作，也要确定 1-3 名维护者。其余的人将负责 PR，就像 GitHub 一样。
-
可发现性——如果人们无法轻松找到组件、了解其工作原理并在代码中使用它们，那么库的作用就不大。如果您将组件分享到bit.dev，您的库将拥有开箱即用的可发现性：组件搜索、可视化预览、标签、实时演示、示例、从代码中提取的 API 参考以及测试结果。这样，您将获得一个用于搜索、选择和使用组件的一体化门户。如果没有（或在此基础上），您可以添加 Storybook 文档门户和/或您自己的网站来记录组件。Codesandbox也很有用。
-
协作- 当另一位开发人员（可能来自另一个团队或另一个国家）需要更改你库中某个组件的某些内容时，会发生什么？他们是否必须亲自向你的代码库提交 PR，然后祈祷并等待？对许多人来说，这太麻烦了，即使你强迫他们这样做，他们也可能不会采纳。相反，应该允许任何开发人员开发组件并提出更新建议，然后由你（和设计师）进行审核。使用 Bit，开发人员可以直接在自己的项目中进行这些操作，而无需进行任何设置或等待 PR。了解其他人在做什么并进行沟通，总比让他们复制粘贴代码并在你不知情的情况下在他们的应用程序中进行更改要好得多。
请记住，库只是另一个用于在两个代码库之间共享组件的代码库集合。它们扩展性差，老化速度慢，并且会带来额外的开销和工具需求。通常情况下，直接通过云在应用程序之间共享组件会更好。
CDD 对开发团队的益处
利用 CDD 开发团队可以享受更快的开发时间、更多的代码重用、更好的 TDD 和统一一致的 UI 设计系统。
人们可以访问已编写的组件进行编码，并协作进行更改。新功能或应用只需调整和微调基础组件，并避免在生产过程中发现错误。
代码共享还意味着需要维护的代码更少，因此您可以专注于构建新事物。当您从组件开始构建时，您还可以让所有人使用相同的构建块保持一致，从而使您的整个开发工作流程变得标准化，同时又不失灵活性。
一些团队报告称，基于以 React 组件形式实现的 UI 组件设计系统的模块化组件，开发速度最高可提升 60%。一些组织发现，通过采用持续开发 (CDD)，他们可以减少约 30% 的代码库。Uber 、Airbnb、Shopify等公司正在转向组件化。
结论
我个人认为 CDD5 更有效并不奇怪。正如Brad Frost在《原子设计》一书中所言，模块化和组合性是物理、生物、经济等领域效率的基础。在软件领域，模块化也带来了同样的优势：速度、可靠性、简洁性、可重用性、可测试性、可扩展性和可组合性。模块化确实更胜一筹。
在我们的应用程序前端，通过持续开发 (CDD)，我们还为用户提供了贯穿整个产品和功能的一致 UI 和体验。这让他们喜爱我们构建的产品，并感到更加满意。实现共赢。
谢谢阅读！🍻
中等的