22 y.o. front-end developer with a special love for learning and creating
This story contains new, firsthand information uncovered by the writer.
The writer is smart, but don't just like, take their word for it. #DoYourOwnResearch before making any investment decisions or decisions regarding your health or security. (Do not regard any of this content as professional investment advice, or health advice)
This story will praise and/or roast a product, company, service, game, or anything else people like to review on the Internet.
前端开发人员经常面临与应用程序架构相关的问题。它需要使用一种能够轻松扩展并在应用程序模块之间提供松耦合和高内聚性的架构。
本文讨论功能切片设计架构,因为在我看来,它是可用选项中最好的。它还探讨了 FSD 的思想以及该架构方法解决的问题。
我们将 FSD 与经典和模块化架构进行比较,并检查它们的优缺点。
首先,让我们区分三个概念:层、切片和段。
层、切片、段
层是顶级目录和应用程序分解的第一层。它们的数量有限(最多 7 层)并且是标准化的,尽管其中一些是可选的。
目前,分为以下几层:
层数
这些层有助于组织代码库并促进模块化、可维护和可扩展的架构。
Github 层
特征切片设计的关键特征之一是其层次结构。在此结构中,实体无法使用特征中的功能,因为特征在层次结构中处于较高位置。
同样,功能不能使用小部件或进程中的组件,因为上面的层只能使用下面的层。这样做是为了维持仅沿一个方向引导的线性流动。 层结构
在每一层中,都有子目录——切片——应用程序分解的第二层。在切片中,连接不是抽象事物,而是具体的业务实体。切片的主要目标是按代码的值对代码进行分组。
切片名称并不标准化,因为它们直接由项目的业务领域决定。例如,在照片库中,可能有照片、相册和图库等部分。社交网络需要帖子、用户和新闻源等切片。
密切相关的片段可以在结构上分组在一个目录中,但它们必须遵守与其他片段相同的隔离规则 - 不应对该目录中的代码进行共享访问。
切片
每个切片由段组成。段有助于根据用途划分切片内的代码。根据团队的协议,段的组成和命名可能会发生变化。以下几段比较常用:
每个切片和段都有一个公共 API。公共API由index.js或index.ts文件表示,它允许仅从切片或段中提取必要的功能到外部,并隔离不必要的功能。索引文件充当入口点。
公共 API 规则:
公共 API 简化了导入和导出的工作,因此在更改应用程序时,无需更改代码中各处的导入。
公共API
层越高,与具体业务节点的联系越多,包含的业务逻辑也越多。层越低,层中的抽象性、可重用性和缺乏自治性就越多。
层的抽象
特征切片设计的任务之一是实现松耦合和高内聚。了解 FSD 如何实现这一结果非常重要。
在OOP中,这些问题早已通过多态、封装、继承、抽象等概念来解决。这些概念确保了代码的隔离性、可重用性和多功能性,根据组件或功能的使用方式获得不同的结果。
功能切片设计有助于在前端应用这些原则。
抽象和多态性是通过层来实现的。由于较低层是抽象的,因此它们可以在较高层中重用,并且根据条件,组件或功能可以根据指定的参数或属性以不同的方式工作。
封装是通过Public API实现的,将不需要的东西以切片和段的方式与外部隔离。对切片内部段的访问受到限制,并且公共 API 是从切片或段访问功能和组件的唯一方法。
继承也是通过层实现的,因为较高层可以重用较低层。
相信您已经多次接触过经典建筑。由于其简单性,大多数作者在教育文章和 YouTube 视频中使用它。古典建筑没有具体的标准。但是,经常可以看到以下格式:
经典建筑
经典架构适用于无需持续维护的小型项目或宠物项目。
功能切片设计凭借其概念和标准,可以防止经典架构的问题。
然而,使用 FSD 的开发人员的理解和技能水平应该高于使用经典架构时的理解和技能。通常,经验不足 2 年的开发人员没有听说过 FSD。
然而,在使用功能切片设计时,需要“现在”而不是“以后”解决问题。代码中的问题和与概念的偏差立即变得显而易见
简单的模块化架构有几个缺点:
似乎在任何复杂或中等复杂的项目中,功能切片设计应该优先于简单的模块化架构。 FSD 解决了许多基本的架构问题,并且几乎没有缺点。
就简单性和开发速度而言,简单的模块化架构可能比 FSD 有优势。如果需要 MVP 或者正在开发一个短期项目,简单的模块化架构可能比 FSD 更合适。但在任何其他情况下,功能切片设计看起来更可取。
FSD 是一种年轻的建筑方法论。然而,它已经被许多银行、金融科技、B2B、电子商务公司等所使用。以下是包含公司列表的 GitHub 问题的链接: GitHub 问题。
在发布本文时,包含 FSD 官方文档的 GitHub 存储库拥有超过 1.1k 颗星。该文档正在积极扩展,FSD 开发团队以及 Telegram 和 Discord 社区可以 24/7 全天候帮助人们解决与架构相关的问题。
这种架构的潜力受到高度重视,并且在全球大公司中广泛使用。如果采用得当,FSD 有潜力成为前端开发领域的主导架构解决方案。
功能切片设计是前端开发人员应该了解并能够使用的一个有趣且有价值的发现。 FSD 可以为团队提供灵活、标准化、可扩展的架构和开发文化。然而,利用该方法的积极方面需要团队内的知识、意识和纪律。
FSD因其清晰的业务导向、实体定义、功能组成和应用程序的组件组成而在其他架构中脱颖而出。
您还可以独立探索项目中 FSD 使用示例和官方功能切片设计文档:
这篇文章可能很长,但我希望您学到了一些新东西。我很感激您读完这篇文章。
如果您有任何想法或疑问,请随时发表评论!
也发布在这里