前端代码组织，不论技术栈的 AI 时代 🤖

Source: Dev.to

AI 时代的前端架构

前端开发变得日益复杂。它必须处理用户需求、功能增强、业务领域逻辑、错误处理、性能优化等。一个结构良好的前端架构能够确保新代码与旧代码之间的内聚性。

AI 代理时代 🤖

即使有 AI 驱动的编码工具，干净且组织良好的代码仍然至关重要。缺乏清晰的结构，AI 可能会把解决方案搞得过于复杂。AI 代理会从代码组织中推断领域逻辑；模式越清晰、一致，代理所需的上下文就越少，从而产生可预测的结果。

经验法则： 遵循模块化的代码组织方式。

什么是模块化方式？

模块化方式将一个解决方案或用户需求拆分为更小的单元，每个单元只承担单一职责。这使得长期维护更容易，也简化了添加新功能的过程，无论是简单还是复杂的功能。

为什么不能仅依赖框架的默认结构？

框架和库通常会提供一个起始项目布局，但随着应用的增长，职责会交织在一起。我们需要把大型需求拆解为自包含的单元（模块），这成为我们的责任。

用例：员工概览页面

设想一个后台管理面板需要一个新的 员工概览 页面，具备以下功能：

Page: Employees Overview
 - Filter (search, role, age range)
 - List employees
 - Open modal for editing an employee
 - Open modal for adding a new employee

提议的架构

下面是一个以块状方式粗略展示的思路：

我们可以使用模块化结构组织代码，将该功能拆分为独立的块，称为 模块：

project
├───common
│   ├───components
│   │   └───Modal
│   ├───hooks
│   │   └───useUserLanguage.ts
│   └───models
│       └───user.ts
├───core
│   ├───authentication
│   ├───i18n
│   ├───translations
│   ├───router
│   ├───api
│   └───store
├───modules
│   └───employees-overview
│       ├───EmployeesOverview.tsx   // Main component
│       └───components
│           ├───employee-filter
│           ├───employee-list
│           ├───employee-add
│           └───employee-edit
│               ├───hooks
│               │   ├───useFetchUser.ts
│               │   └───useUpdateUser.ts
│               ├───components
│               ├───helpers
│               ├───models
│               └───EmployeeEdit.tsx
└───lib
    └───utils

文件夹职责

• common（亦称 shared）：在各模块之间可复用的代码，按组件、hooks、helpers 等组织。
• helpers（亦称 functions）：执行特定任务的纯函数。
• models：实体定义，理想情况下与后端结构保持一致，以实现单一真实来源（例如处理日期格式）。
• modules：基于业务目标的特性代码。
• core（可选）：应用的基础代码，如认证、路由、API 客户端和状态管理。将这些放在专门的文件夹中便于定位。
• lib（亦称 utility）：与领域逻辑无关的通用技术函数，可在整个代码库中使用。

结论 💞

以特性、职责和块为思考单位。模块化、结构良好的代码库能够帮助你的团队和 AI 代理更高效地维护和扩展应用。 💪