在我职业生涯的某个阶段，我接手了一个大型的 React 应用，一开始看起来还不错——直到出了问题。😅

随着时间的发展，该项目不断演变，但它的成长却不再优雅，反而变成了一头难以驾驭的庞然大物。

❌ 自定义的状态管理器 — 调试和扩展都很困难。
❌ 庞大的UI组件 — 混合了业务逻辑、API调用和UI。
❌ 为不同的客户端 — 但所有版本共享同一个代码库。
❌ 发布过程非常痛苦 — 修改一处可能会影响完全不相关的部分。

终于有一天，我意识到这不可持续。

这是一段关于我如何将那个混乱的前端重写为模块化、可扩展和易于维护系统的经历。

……

• 前端代码一团糟？模块化才是关键！

• 将你的代码拆分为组件、功能和领域。

• 让界面、逻辑和数据处理三者各自独立。

• NX 单仓库解决了相互依赖性难题。

  从简单开始，逐步改进，并用工具规范结构。

一开始，我们的 React 应用曾是一站式单体结构：

• 自定义的状态管理。我们自己搭建了状态管理，而没有使用Redux等工具（当时Context API还不够成熟）。

• 这样的情况，UI和逻辑紧密结合在一起。一个组件可能超过500行代码。

• 仓库中存在多个UI版本。每个客户端需要的UI稍有不同，但没有把它们分开，而是让所有版本在同一个代码库中共存。

• 一个仓库包揽了所有事情，包括状态、API 调用、业务逻辑和 UI，这不仅让维护变得很麻烦，也让新来的开发者很难上手。

最大的烦恼：

🚨 扩容根本行不通。每增加一个客户，麻烦就成倍增加。
🚨 代码复制粘贴满天飞。重用功能只意味着更多的复制粘贴。
🚨 UI的改动简直就是噩梦。每个客户要求不同，我们不得不写一堆if语句来搞定各种布局。

学到的教训:

一个包含所有内容的单一存储库不仅效率低下，而且它就像一颗定时炸弹。

此处略去内容

发现一团糟，我决定将应用程序拆成单独的仓库，每个仓库处理特定的问题。这样，我决定将应用程序拆成单独的仓库，每个仓库处理特定的问题。

(Note: The sentence is slightly redundant after incorporating the suggestions, but to maintain the flow and naturalness of the Chinese language, I kept the slightly repetitive structure as suggested for better readability and fluency.)

新的模块结构：

✅ 一个React组件库 📦

包括了状态部分，以及与API的交互，还有核心功能部分。

• 单一事实来源的逻辑 — 不再有重复了。

✅ 独立的UI模组 🎨

这只是 Bootstrap CSS 的纯样式扩展，不包含任何 JavaScript。

• 用户界面现在可以使用不同的布局而不会影响应用程序的逻辑结构。

✅ 一个用于 Pages 和 UX 的 React 应用 🏗️

• 负责路由、布局和页面设计等工作。

  现在可以使用相同的 API 和组件库构建各种不同的应用程序。

有什么变化吗？

🚀 更高的灵活性——我们可以根据需要轻松调整应用程序的布局，而无需复制代码。
🚀 更便于维护——可以专注于UI开发，而不必担心业务逻辑。
🚀 职责划分更清晰——每个模块都有自己明确的任务。

👉 重构确实是个游戏规则的改变者。但它带来了一个新挑战：管理这些相互依赖的包。

此处省略内容

在完成了项目拆分后，我们将项目拆分成多个代码库，又碰到了一个问题：

⚠️ 本地开发变得痛苦. 我们依赖于npm链接来跨多个相互依存的包进行开发。
⚠️ 同步更改变得很慢. 对任何一个包的更新都必须在其他相关包中手动管理。
⚠️ 新人上手变得复杂. 新来的开发人员必须手动配置多个仓库才能开始工作。

我意识到管理这些单独的仓库本身已经变成了一件麻烦事。

方案：NX 单仓库

为了简化开发过程，我们将所有模块移动到了 NX 工作空间。

✅ 统一的仓库结构 — 所有项目都集中在一个地方。
✅ 内置的依赖关系图 — NX 自动理解模块间的连接。
✅ 更快的构建 — NX 只重新构建了更改的部分。

👉 迁移策略非常重要。为了避免中断，我们采取了以下措施：

1. 在 NX 工作区从头开始创建了这个应用。
2. 复制了现有的 React 组件库，没有改变逻辑，只是将类组件改写为 hooks。
3. 引入了两个额外的模块以优化架构并增加新功能。

有什么变了？

🚀 模块化、可扩展的开发 — 每个团队现在可以独立开发自己的包，不会影响其他团队。
🚀 更快的迭代 — 再也不用担心 npm 链接的问题了！
🚀 更好的协作 — 每个团队专门负责前端的不同部分。

👉 借助 NX，我们终于有了一个既模块化又便于维护的系统。

下一步：优化NX架构设计 🚀

迁移至NX 单一代码库虽然这显著改善了我们的工作流程，但仍存在进一步模块化的余地。下一阶段的重点将放在通过以下方式增强可维护性和可扩展性：

✅ 将功能拆解成微小包
目前，我们的 React 组件库包含核心功能和特定功能的逻辑部分。因此，为了更好地遵循NX的推荐做法，我们将会：
我们将会更好地遵循NX的推荐做法，因此我们计划：

• 将与特定功能相关的模块提取为独立的 NX 包（例如，@myorg/task-list，@myorg/profile）。
• 确保每个功能包都是独立且可重复使用的，可以在多个应用中使用。
• 减少各功能之间的依赖关系，以便简化开发和部署。

✅ 使用NX Storybook介绍文档
为了让开发体验和效率以及协作提升，我们打算：

• 把 NX Storybook 集成到我们的 UI 组件 和 功能模块 中。
• 提供 交互式文档，让开发人员能预览和测试组件。
• 标准化我们的 设计系统和 API 协议 以保持项目间的一致。

通过这些改进，我们的NX工作区将变得更加可扩展、文档完备和对开发者友好——使团队能够更高效地工作，并且功能之间界限分明。

此处为空白

1️⃣ 尽早开始模块化的设计。 不要等到项目变得难以管理时再开始。
2️⃣ 从一开始就将UI、逻辑和状态分离出来。 这可以节省大量的重构时间，避免无尽的加班。
3️⃣ 避免不必要的复杂性。 模块化应该让事情更简单，而不是更复杂。
4️⃣ 对于依赖性强的项目，考虑使用单仓库。 NX为我们解决了许多问题，是一个很好的解决方案。
5️⃣ 优雅地迁移是关键所在。 分步进行可以避免停机时间。

模块化并不是为了让事情变得更复杂，而是为了使它们更易于管理。

💡 如果我现在开始一个新的前端项目，我会：

• 使用流行的前端框架或库，如React或Vue；
• 采用模块化编程；
• 集成Git这样的版本控制工具；
• 使用构建工具，如Webpack或Vite，来优化开发流程；
• 关注性能优化和可访问性，并确保良好的用户体验。

✅ 从第一天起就使用组件化架构。
✅ 立即将UI与业务逻辑分离。
✅ 考虑使用单仓库来管理相互关联的项目。
✅ 确保团队对其模块有管理权。

🔹 你有没有重构过乱七八糟的前端代码库？
🔹 你通常用什么方法保证项目的模块化处理呢？

💬 留言吧——我很想听听你的想法！

🔗 关注我下一篇关于微前端的文章：何时使用，何时又不使用它们呢！

🔥 喜欢这个帖子吗？那就和你的开发朋友分享吧！