话说天下大势，合久必分，分久必合。这句老话放在前端工程演进的漫长历史里竟然也是出奇的贴切。回望行云2.0那个时期，原本普普通通的一个业务项目，就像是一颗被施了魔法的种子，短短两三个月的功夫，就疯狂生长成了一个容纳了百十来个子应用的庞大“生态系统”。这些子应用来自五湖四海，各自施展浑身解数，为JDer们提供着琳琅满目的产品功Neng。

不过不管您用没用过这些出色的产品工具们，咱今天dou不打算讨论子应用们，而是转回头审视行云前端工程Zui初的架构模样，着实还是有些惨不忍睹的。对于一个服务着上万JDer研发的业务而言，产品迭代如同奔腾不息的河流，不Neng有片刻停滞。业务在飞跑，我们如何停下来好好思考呢？Ke以的，不要停，一边跑一边搞。

至暗时刻：单体架构的“七宗罪”

为什么说是血泪史呢？这绝非危言耸听。彼时的行云前端，背负着十多万行代码的沉重包袱，想要在短时间内完成治理几乎Ke以说是天方夜谭。哪怕是在我们确定了改造方向并且开始实施到中途时dou无数次的怀疑过自己，怀疑过是否决策正确，无数次的质疑过这样的努力是否真的是有价值的，痛苦的日子真的想过还是放弃算了。是的，真的hen难。

1. 代码结构混沌：剪不断理还乱

这个单体应用身兼数职，既承担平台基础功Neng搭建，又涉足协作域业务开发，甚至还包含一些并非严格意义上子应用，却拥有顶级路由的特殊页面如开放平台、开发者后台、应用商店等。不同业务逻辑在同一代码库中交织缠绕，业务之间耦合度极高。任何一处业务逻辑的修改，dou可Neng像推倒多米诺骨牌一样，引发一系列难以预估的问题，极大增加了代码维护与 的难度。

虽然我们也曾尝试用/modules目录来区分不同的业务领域，但现实hen骨感，文件夹之间的组件引用关系简直是一团乱麻。举个真实的例子，在A业务模块开发过程中，开发人员可Neng为了图省事，直接引用了B业务模块里的某个组件，完全没把业务分层当回事。结果呢？一旦B模块有了变动，A模块跟着遭殃，这种依赖关系就像一团乱麻，根本理不清。

2. 构建效率低下：漫长的等待

协作域作为业务迭代的“主战场”，geng新频率极高，两三周可Neng就要发好几次版。但当时我们用的全量构建方式，简直是灾难。每次发版，不仅协作域的代码要geng新，连带着平台业务也会被强行geng新。那时候Zui怕听到的就是一句：“行云，又双叒叕白屏了……”

整个工程所有业务均统一采用Vue CLI进行构建。Vue CLI虽具有上手容易、配置简单等优点，但随着业务规模的不断扩大和复杂度的提升，启动慢、构建慢的问题愈发明显。构建过程中也会有不必要地编译和打包一些无需geng新的代码，延长了构建时间，降低了开发效率。动辄八分钟的构建时间，足以让开发者的耐心磨灭殆尽。

3. 静态资源臃肿：无法承受之重

平台积累了大量臃肿的静态资源，尽管我们Zuo了代码分割，Neng够Zuo到非必要业务不加载，但作为支撑Vue子应用的平台，必要的公共依赖无法轻易翦除。而且平台自身的架构也对这些公共设施有依赖需求，导致静态资源占用空间始终居高不下严重影响应用的加载性Neng。

4. 商业化交付的噩梦

当行云迈向商业化进程，业务切割不清的问题愈发棘手。客户需求千差万别，比如有的客户只想买代码库，不要协作域，只要工作台，还得配开放平台和帮助中心。面对这种需求，因为代码结构缺乏清晰的业务边界，我们只Neng通过大量的手动删改代码来满足。这一过程不仅耗时费力，而且极易因人为失误引入新的问题，OMG…只Neng一把鼻涕一把泪地删删改改日日到天明。

破局契机：内外同源与绞杀者模式

我们幸运地迎来了一个完美的契机。当计划开展新业务时面临着诸多挑战。一方面要保证新业务与现有业务在UI风格、交互方式以及与后端API交流方式等方面保持一致；另一方面要确保新业务的加入不会增加现有业务的构建时间，且不会引入geng复杂的依赖关系。简单来说就是要实现工程的易 性，同时满足开闭原则，这对工程架构提出了极高的要求。

为什么叫绞杀计划呢？这个idea源于老司机一次聊天时提到的“绞杀者模式”。概括来说就是：绞杀者模式是一种软件设计模式，用于逐步替换现有的大型系统或应用，通过新系统逐渐接管旧系统的功Neng，Zui终完全取代旧系统，而无需一次性完成整个系统的重写。这种方式Ke以减少风险，确保平稳过渡。

这在当时一筹莫展、选择艰难的我kan来仿佛醍醐灌顶一般kan到了曙光。于是故事就从这里开始了。

重构之路：Monorepo架构的落地

改造后的工程采用 monorepo框架，借助 Nx 与 pnpm 管理，遵循模块化、微前端等原则，明确 apps/ 应用模块与 packages/ 共享模块职责。在开发体验优化上，部分项目迁移至 Vite，利用缓存提升效率；云端构建通过代码分割、缓存优化等提高构建速度与资源利用率，整体具备良好 性，为业务发展提供geng坚实的架构支撑。

1. 目录结构的重新定义

在新的工程结构中，主要包含以下部分，我们彻底告别了过去的混乱：

• apps/: 包含多个独立的应用

这里不再是所有代码的大杂烩，而是各个独立应用的家园：

platform: 独立的平台应用，用于加载其他子应用，提供统一平台入口。作为基于Vue搭建的平台，不仅Neng够跨技术栈加载非Vue技术栈的应用，对于vue技术栈的应用还无私地奉献出了全局共享的Vue实例、router、vuex等等，同时连带全局组件库以及axios实例的分发，为依赖Vue技术栈的子应用提供全方位的支持，尽心哺育着有全局依赖需要的子子孙孙们。

admin: 负责系统配置、用户管理等后台管理功Neng。

jacp: 核心业务应用，实现主要的协作域业务逻辑。

open: 负责行云开放平台及应用商店、开发者后台、文档管理等业务功Neng。

ai-assistant: 提供调用AI-Chat的用户交互界面在平台中使用iframe加载其页面。

• packages/: 包含可复用的模块和库

共享模块提供了Ke以在多个应用中复用的功Neng和组件：

common: 为共享vue实例的子应用导入并配置了必要的依赖，提供了一个共享的环境和资源。

common-service: 封装通用的后端服务调用和数据处理逻辑。

utils: 提供各种通用的工具函数。

components: 可复用的UI组件。

tailwind-config: 集中管理Tailwind CSS配置，确保样式的一致性。

xingyun-elements: 存放web-component组件。

2. 技术栈的升级与统一

在这次改造中，我们对技术栈也进行了大刀阔斧的调整：

◦ 构建方案和工具的选用：业务工程使用vue-cli/vite；基建pkg使用vite/tsup

部分项目迁移到Vite，利用其快速的开发服务器和构建Neng力。利用缓存提高启动速度，减少资源消耗，以提高开发效率。Webpack构建的应用则使用硬件缓存。

◦ 移除Windi CSS，全工程迁移到Tailwind CSS

行云前端hen早就实践了原子样式，在摸索阶段，由于缺乏统一的使用规范，不同同学采用不同的使用姿势。例如对于同样的样式效果，有人用w-24px，有人用w-24。同时有些开发者在组件中既采用BEM命名风格设置样式，又在各个class里使用@apply引入原子样式，这种Zuo法既无法享受原子样式无需费劲命名class的优势，又不Neng有效重用class以减少构建体积，还浪费了构建时的资源。直到有一天我们发现，windicss停止维护了。。。这是上天给我们悔过的机会啊，是时候把乱象丛生的杂草整顿干净了。我们集中管理Tailwind CSS配置，确保样式的一致性。

◦ 工具引入：pnpm workspace, nx

Monorepo管理工具：pnpm workspace + Nx 。通过Nx的依赖图分析，我们实现了增量构建，只构建产生变化的部分，大大提高了开发效率。

关键策略：模块切割与构建瘦身

基于以上目标，我们制定了以下具体的改造路线：

1. 模块切割：分家过日子

把平台和业务代码分家，公共依赖和业务应用实现分离。业务模块分离：划分几个相对独立的，有自己的路由、状态管理的子应用，均可独立开发运行和发布，放在apps/下。每个应用模块dou是相对独立的，有自己的路由、状态管理和UI组件，均可独立开发运行和发布。它们Ke以共享packages中的代码。

2. 构建瘦身：拒绝全量构建

避免全量构建了发布哪个应用就只构建这个应用相关的依赖，平台别再背锅白屏了。Monorepo的结构：应用独立化后可按需构建，提高单个应用构建速度和资源利用率。构建配置添加并行处理以提高构建速度。减少低频变化包的构建。

3. 代码断舍离：清理历史包袱

在数年的开发过程中，虽然沉淀了不少全局复用的组件，但随着业务迭代，部分组件Yi被废弃，或者虽在UI层面不再使用，但仍在一些边角业务中少量存在。这些废弃组件依旧躺在代码库的components目录里白白占据代码体积，增加了代码维护的复杂性。我们痛下决心，废弃组件、冗余代码，统统清理掉。

成果与反思

这次改造，我们实现了模块化、微前端、组件驱动开发和主题定制等架构设计原则，使得行云前端小工程geng加轻量化、可 性和易于维护。

性与可维护性升级：采用分层架构，保持良好的独立性和可 性。模块化开发原则：构建高内聚低耦合的独立模块，确保单一职责、清晰接口和可复用性，以提升代码的可维护性、可测试性和可 性。组件驱动开发： 关注于创建和完善单个组件，然后将这些组件组合成geng复杂的结构，Zui终形成完整的用户界面。主题定制：使用Tailwind CSS实现灵活的样式定制。

新旧平台Lighthouse同一应用跑分对比，性Neng提升显著。通过利用Webpack的文件级缓存和Nx的缓存和增量构建功Neng提高构建速度。在行云部署缓存实现：行云部署的缓存基于构建镜像存储，通过将源码拷贝到缓存目录下Ke以显著提高缓存读取效率。

但是现在回想起来只要我们在Zuo正确的事情，那就是值得的。写这篇文章是为了分享我们的经验和教训，希望Neng帮助其他人在面对类似问题时有所启发。同时这也是一次自我反思和的过程，帮助我们geng好地理解和改进我们的工作流程和技术选择。

延伸阅读

Ru果你想了解geng多细节，Ke以移步以下文章：

详情请移步：行云前端重构之路-Monorepo实践篇

详情请移步：Tailwind CSS 在 Monorepo 中的实践

使用JModule快速实现宿主平台：解锁微前端平台开发

Shadcn UI + React Hook Form + Zod 在行云工程中的实践：Headless UI真香～

Monorepo 在商业化产品交付中的痛点与改进方向思考：平衡的艺术之美

既要让行云前端轻装上阵，又要让它跑得geng快、geng稳、geng优雅！这条路虽然充满荆棘，但风景独好。你走过这样的路吗？

---