自1960年代以来,
模块化一直是软件开发的关键原则之一。 应用该原理为编程带来了很多有用的东西。 模块化有助于有效使用职责分离原则,从而提高了创建,重用和构建代码的能力。
如今,模块化原理在软件设计中的应用已经以一种新的形式体现在组件中。 这是组件驱动开发(CDD)。 用于开发用户界面的现代库和框架(如
React ,
Vue和
Angular )以及面向CDD的工具(如
Bit )使您可以基于模块化组件创建应用程序。 程序员可以使用必要的模式和工具来独立开发组件并构建组件组合。
组件是应用程序接口的明确定义的独立片段。 作为组件的示例,您可以引用用于显示聊天消息的实体,例如按钮,滑块,窗口。 了解CDD的功能并了解如何将这种方法应用于开发,我们可以使用组件作为应用程序的基础。 这在创建软件项目时为我们提供了有用的一切,这意味着应用了模块化编程的原理。
如果仔细观察
Web组件领域中正在发生的事情,您会注意到CDD正在成为前端开发的标准化方法。
我们今天发布的翻译材料是基于组件的开发指南。
用户界面开发中的CDD
按位工作:在组件上创建,隔离,重用和协作简而言之,基于组件的开发通过创建松耦合的独立代码块来设计应用程序。 它们每个都有一个接口,旨在组织与系统其他部分的交互。 许多组件通过组合彼此组合,形成一个模块化应用程序。
例如,在创建React应用程序时使用CDD意味着它们首先创建构成应用程序基础的组件,然后再从中组装应用程序的较大部分,例如整个页面和大型功能块。
CDD与
原子设计 (
这里是有关此主题的有用材料)以及开发Web项目客户端部分的方法有关,称为“
微型前端 ”。
CDD有助于将大型项目的开发过程分解为单个组件的较小开发过程。 每个组件的设计均独立于应用程序的其余部分,并且在考虑与系统其他部分进行交互的可能性的情况下进行创建。 将每个组件设计为独立实体会为开发人员提供许多有用的功能。
Eddie Osmani概述了使用CDD的一些主要优点。 他按照称为
FIRST的一组原则设计了它们。
这些原则是:
- 加快发展(更快的发展)。 开发人员致力于创建单独的组件这一事实允许使用高度专业化的API创建应用程序的模块化部分。 这意味着一方面可以快速开发组件,另一方面可以更轻松地将组件开发到项目开发时所要求的质量水平。
- 简化支持(简化维护)。 当您需要修改或更新应用程序的一部分时,可以扩展或更新组件,而不是重构应用程序的大部分。 可以将其与医疗程序进行比较,在单独的器官上进行手术,从而取代了涉及对人体几乎所有部位进行干预的手术。
- 更好的代码重用能力。 由于使用了责任分离的原理,在从组件创建完成的应用程序期间,可以重用或扩展组件。 这比一次又一次重写它们的需求要好得多( 这是此主题的资料)。
- 提高应用TDD(更好的TDD)方法的能力。 在模块化组件的开发过程中,这比使用其他方法实施旨在验证组件狭窄功能的单元测试要容易得多。 结果,事实证明,测试由组件组装的大型系统更加容易。 事实是,当使用模块化方法时,开发人员更容易理解系统的一个或另一部分究竟负责什么。
- 缩短学习曲线(更短的学习曲线)。 当开发人员不得不为他处理一个新项目时,事实证明,理解各个组件的本质和结构比深入研究整个项目的复杂性要容易得多。
- 改善建模系统的功能(对系统进行更好的建模)。 当系统由模块化组件创建时,开发人员将更容易理解系统的总体结构,了解系统并学习如何影响系统。
CDD工具
如果开发基于组件,则意味着程序员需要专门的工具。 这些工具旨在创建组件,测试它们,组织对它们的一般访问并支持它们之间的协作。
尤其重要的是,隔离设计和测试组件。 这使它们可以以可在应用程序中使用的独立单元的形式工作。 此外,支持组件的重用以及共享组件的能力也很重要。 这样一来,作为主要项目团队成员的一个人就无需重新发明轮子,轮子已经以组件的形式被团队中的一位成员发明了。
这里有一些有用的工具,可以帮助您组织CDD风格项目的工作。 在以下部分之一中,我们将讨论为CDD原理的实际实施推荐的项目体系结构。
▍位:个人和团队开发组件
Bit是一种
开源工具,其创建目的主要是为了支持CDD方法论的实际应用。
这是关于比特
的视频。 该工具可帮助您开发组件,在组件上进行协作以及使用它们创建Web项目。
关键是使用Bit意味着您可以隔离作为项目一部分开发的组件。 说-在应用程序或库中。 Bit支持命令行工具,它有助于组织组件及其所有文件和相关性的封装。 Bit允许您独立开发和测试封装组件的虚拟表示。
这意味着可以在应用程序内创建的组件配备其所有依赖项,并将其封装并转换为可在应用程序外部使用和测试的实体。
此外,Bit允许您打包独立的封装组件,并使用
云工具组织它们的共享。 这使从事项目工作的团队可以使用共享的所有组件。 Bit社区有大约50,000名开发人员。 他们的努力创造了成千上万的开源组件供所有人使用。
使用封装组件进行项目开发借助云平台的功能,开发团队可以在其应用程序中安装开源组件。 团队成员还可以直接从工作环境中为组件作者提供改进组件的想法。 Bit扩展了Git跨项目跟踪和同步组件源代码更改的能力。 这使开发人员能够管理组件更改和更新。
位存储组件依赖关系的完整树。 这使开发人员有机会了解组件的更新如何影响相关的组件,以及在对组件进行更改时项目中可能“破坏”的内容。 这意味着,由于有了Bit,程序员可以使用一个成熟的环境来组织基于组件的开发,使您可以创建组件,对其进行测试并组织有关组件的联合工作及其联合使用。
CDD中的云功能Bit的另一个有用功能是,该平台允许开发团队不仅使用单个界面使用其组件,而且还可以使用公共领域中共享的其他组件,并与这些组件的作者进行交互。
界面设计人员,客户项目的代表以及程序员可以在项目的联合工作过程中使用通用的可视化工具。 这弥合了设计师和程序员之间的鸿沟。 而且,应该指出,在这种情况下,不仅设计人员和程序员受益,而且遇到较少异质性和错误的应用程序的最终用户也会受益。
这里 ,
这里和
这里是有关使用Bit的各个方面的一些材料。
UIUI组件的开发和研究:StoryBook和Styleguidist
StoryBook和Styleguidist是使用React快速开发用户界面元素的环境。 这两个项目都是加速组件开发的好工具。
故事书
StoryBook是用于快速开发UI组件的环境。 它使您可以使用组件库,查看组件的各种状态,参与组件的交互式开发和测试。
在StoryBook工作StoryBook可帮助设计与应用程序隔离的组件。 这有助于提高组件的可重用性并提高组件的可测试性。
使用StoryBook,您可以查看存储在库中的组件,并在线尝试其属性。 立即可视化对组件所做的更改,而无需重新加载页面。
以下是在StoryBook中创建的组件的一些示例。
有许多插件可以使用StoryBook加速组件的开发。 这使您可以减少在更改组件代码与其形成可视表示之间花费的时间。 应该注意的是,StoryBook除了React之外,还支持
React Native和
Vue.js。React styleguidist
React Styleguidist是一个组件开发环境。 该环境包含一个支持热启动的开发服务器。 它还具有一个交互式样式管理系统,该系统显示组件的
propTypes
并为开发人员提供基于.md文件的组件使用示例的可编辑示例。
React styleguidist该平台支持JavaScript ES6,Flow和TypeScript。 她无需其他设置即可使用Create React App。 Styleguidist能够自动创建组件文档。 这使该系统可以充当某些团队正在处理的组件的可视化文档门户。
如果您对StoryBook和Styleguidist等项目感兴趣,那么您可能想看看Formidable正在开发的
React Live项目。
StoryBook和Styleguidist之间的区别
在使用StoryBook时,程序员在JavaScript文件中编写“故事”。 与Stuleguidist合作时,他在Markdown文件中编写了“示例”。 故事书一次只显示一个组件的一个变体,而Styleguidist可以显示不同组件的多个变体。 StoryBook非常适合分析组件的各种状态,Styleguidist非常适合生成组件文档和演示组件功能。
使用CDD方法论的体系结构决策
CDD风格的工作意味着在开发应用程序时,首先创建组件。 此外,这些组件应尽可能彼此独立。 这意味着开发人员不仅可以创建“一组组件”。 他还实现了所谓的用户界面组件
设计系统 。
组件既可以在应用程序本身的框架内(即,在同一项目中,在存储库中)创建,也可以在单独的项目(库)中以组件库的形式创建。
像Bit这样的工具可让您隔离和封装组件。 这为开发人员提供了充足的机会来创建,测试,重用组件,并使它们可以在任何地方最终确定-无论它们在何处创建。
如果我们说CDD的使用以项目工作的第一步的形式提供了组件的开发,那么这也意味着这些组件倾向于使其适合于重复使用。 这使您可以在创建各种应用程序时应用它们。 因此,开发人员需要确切地了解他需要做什么才能创建此类组件。 没有什么比花六个月来创建一个
库更糟糕的了,最终没有人会使用它。 不幸的是,许多团队都会发生这种情况。
为什么要创建组件库?
我对你说老实话:Git仓库并不是考虑将原子组件代码存储在其中的可能性而设计的,这些代码计划在各个项目中共享。 为了解决此问题,软件包管理器不适合。 两者都是为了支持代码存储库而创建的,这是可以理解的。 组件不是存储库。
在各个项目中共享组件因此,如果您需要从一个应用程序中获取组件并在另一个应用程序中使用它,则需要创建一个新的存储库。 为了使您免于为每个此类组件创建单独的存储库的不必要工作,大多数团队创建了一个共享存储库,该存储库旨在存储20-30个组件。
当使用Bit等工具时,不需要这样的组件库。 使用此类工具,您可以将组件从应用程序下载到云中,并在其他项目中实现该组件。 如果我们将此工作方案与传统存储库进行比较,则可以说这就像将音乐CD和Spotify进行比较。 的确,如果您接近开发和使用组件库的想法,则Bit和StoryBook等平台的功能将使您可以使用库。
设计库时,您需要做出几个关键的决定。 下面将考虑一些重要的原则,可以帮助您解决这一问题。 这些原则的重点是您的任务是创建独立的组件。 该项目的其余工作类似于Lego构造函数的组装。 如果不遵循开发独立组件的原则,那么有一天您可能会遇到麻烦。 当有人需要与库中的内容有所不同时,麻烦就会开始。 实际上,发生这种情况时,团队将停止使用组件库。
假设您决定创建一个组件库。 如果是这样,我们会为您提供一些技巧,以帮助您解决此问题。
开发面向CDD的高质量库的7条原则

- 标准品 创建库时,您遵循什么开发标准? 组件在哪里? 测试在哪里? 那样式呢? 您正在使用什么技术堆栈? 例如-您打算使用TypeScript吗? 组件如何划分? 例如,“表格”组件是否由“行”和“单元格”组成? 带选项卡的面板是否由单独的选项卡组成(相对于其他类似实体,是否可以问相同的问题)? 我想您已经了解了此建议的含义。 在标准制定过程中包括设计师也很重要。 这样可以确保该库足够灵活,并且可以满足将来可能出现的设计要求。
- 程式化。 您打算如何设计组件的样式 ? 您会将相应的CSS代码链接到每个组件吗? 如果是这样,当设计人员仅需要为使用组件的单独应用程序进行更改时会发生什么? 也许要改善组件与样式的分离,值得使用在JS技术中实现CSS的库吗? 也许值得寻找其他样式设计方法? 例如,使用位,您可以突出显示主题作为单独的组件。 这样的主题可以应用于实现某种逻辑的组件。 这使您可以创建应用程序,在其中将设计和逻辑完全按照开发人员的需求进行组合。 这是使用模块化原理构建的系统的极高灵活性的示例。
- 测试。 您将如何测试库中包含的组件? 使用笑话和酶? 应当全权负责选择组件测试工具的良好组合。 这将允许此类工具帮助您实施CDD方法论。 工具选择不当会干扰工作。 单元测试很好。 但是他们应该检查组件的功能性API,而不是检查其实现的细节。 集成和端到端测试与单元测试一样重要。 当将TDD方法应用于使用CDD的项目时,效果很好。
- 代码汇编过程。 该代码需要编译。 您将如何组织库的代码构建过程? 版本将如何实施? 您是否打算仅从应用程序中复制代码并将其粘贴到库中(可能会对其进行一些修改)? 您是否要为每个组件(Lerna)定义程序集配置,并在发布代码之前将适当的机制应用于代码? 您是否打算多次使用已经提到的Bit来定制适用于所有(或单个)组件的构建过程? 如果组装过程过于复杂,则参与开发将变得更加困难,项目的模块化将恶化。 参与开发所需的学习曲线将变得过于陡峭。
- 代码管理。 谁拥有图书馆? 在相当大的组织中,通常会有前端开发人员团队,有时还有架构师。 他们正在创建一种称为“共享库”的产品。 其他前端开发团队使用类似的库创建应用程序。 通过这种交互方案,使用允许您方便地找到必要组件(位,故事书)的系统非常重要。 也许更重要的是组件用户可以提出组件改进建议的机制。 如果组织中没有这样的机制,则组件用户团队将不希望将其应用程序与库关联,并等待其PR被接受,而他们很可能不会等待。 无需强迫程序员做任何事情。 建立健康的合作是必要的。 如果您不为此而努力,则没人会使用该库。 程序员只需复制并粘贴代码,就没有人对此做任何事情。 而且,这将是您的错误。 如果您是一个小型团队,请明确确定谁在管理代码。 即使没有人一直在参与该代码库,也请选择一些支持该代码的专家。 其余的将执行PR-就像在GitHub上一样。
- 查找组件。 如果程序员找不到所需的组件,无法学习这些组件的工作方式以及无法在代码中使用它们,那么该库将不会带来太大的好处。 Bit具有帮助开发人员查找组件的内置功能。 除了这个平台(或代替它),您可以使用StoryBook的功能或某种自己的解决方案。 Codesandbox平台可为解决与选择组件有关的问题以及为其提供文档的工作提供一些好处。
- 组织组件协作。 当开发人员(可能来自另一个团队,甚至来自另一个国家)需要从您的库中更改与组件相关的内容时,会发生什么情况? 他是否需要更深入地为您的图书馆创建PR,并用手指指望结果。 对于许多开发人员来说,这太复杂了,即使您尝试以某种方式影响他们,他们也不会这样做。 如果您使用简化项目协作的平台,那就更好了。
请记住,库只是为了便于在各个项目中共享组件而存在的存储库。 图书馆的伸缩性不是很好,它们中的代码已过时,它们遭受各种问题的困扰。 使用某种云平台,简单地直接提供要共享的组件可能会更好。
CDD团队的优势
使用CDD原理的团队将从加速开发,提高代码的可重用性,改进的TDD和一致的设计系统界面中受益。
程序员可以访问已编写的组件来编写代码,并且可以一起工作以对组件进行更改。 新功能或应用程序的开发归结为定制和扩展基本组件。 此外,这有助于防止仅在生产中发现的错误。
共享代码尤其意味着减少需要支持的代码量。 这使程序员可以专注于创建新的东西。 当基于组件开发应用程序时,由于每个人都使用单个应用程序构建基块,因此这使工作标准化。 组件方法还有助于提高工作灵活性。
一些团队报告说,由于使用了基于作为React组件集实现的设计系统的模块化组件,他们的工作流程加快了60%。 一些组织发现,通过引入CDD,他们可以从其代码库中删除大约30%的代码。
Uber,Airbnb,Shopify等公司正在引入一种组件化方法。
总结
就个人而言,使用CDD可以提高软件开发效率并不感到惊讶。 据布拉德·弗罗斯特(Brad Frost)称,有关原子设计,模块性和组成的书是生物学,经济学以及许多其他领域中最重要的概念。 软件开发中应用程序的模块化提供了速度,可靠性和易于开发性。 它促进了实体的重用,提高了代码的可测试性和可扩展性。 模块化使开发人员能够在创建复杂系统时使用合成。 所有这些都非常影响应用程序开发的过程和结果。
亲爱的读者们! 您在项目上工作时是否使用CDD方法?
