在软件工程的世界里“重构”这个词往往带着一种悲壮而又充满希望的色彩。它不是推倒重来而是一场精密的外科手术。过去的半年里我独自面对着数百页的遗留代码，经历了一场从技术架构到思维模式的全面洗礼。这不仅仅是一次系统的升级，geng像是一次自我认知的重塑。当Zui后一个Bug被修复，当Zui后一行冗余代码被剔除，我不禁问自己：系统重生了那我呢？

一、 困境与契机：当“屎山”成为日常

在现在的部门待了两年多，眼kan着这套基于 vben2 搭建的后台系统逐渐显露出老态。版本滞后导致的 bug 频发只是表象，真正让人头疼的是内部逻辑的混乱。重复的代码像藤蔓一样缠绕着核心业务，交互设计的割裂让用户怨声载道，geng别提那令人绝望的多环境维护成本。每一次迭代，dou像是在泥潭中行走，既消耗着大量的时间精力，也让技术价值难以得到释放。

之前组内前端配置是三个人，后来按业务线划分，我这条线只剩下两个人在维护。上半年，与我共事的同事休产假，所有的迭代压力瞬间压到了我一个人身上。那一刻，焦虑感油然而生，但随之而来的还有一种破釜沉舟的冲动：这或许就是全量重构系统的Zui佳契机。

我一直在盘算着如何完成整个框架的升级。中间我密切关注着 vben5 的开源进度。在 vben5 尚未完全实现表单和表格的全部功Neng之前，重构计划只Neng暂时搁置。期间，我尝试用 vben3 搭建了两个新项目，但体验并未达到预期，与 vben2 相比提升有限。于是我选择继续等待，等待那个成熟的时刻。

二、 重构的哲学：整合、优化与重构

hen多人认为重构就是“重写”，其实不然。正如《重构：改善既有代码的设计》书中所定义的：在不改变软件可观测行为的前提下调整代码结构，提高软件的可理解性，降低变geng成本。这是一项经济适用行为，而非道德行为。Ru果它不Neng让我们geng快geng好地开发，那它就毫无意义。

在这次半年的战役中，我将核心策略为三个词：整合、优化、重构。

1. 整合：收敛碎片，统一战线

整合是我在重构过程中Zui早规划的，核心在于把分散、重复的功Neng逻辑收敛到统一的模块或组件中。要想Zuo好整合，必须熟知业务。Ru果没有完整的文档，那就只Neng通过阅读代码逻辑，抽丝剥茧，出流程图和逻辑图。

在旧系统中，涉及到表格内编辑时交互方式五花八门：有的需要点击编辑切换整行状态，有的需要弹出表单，有的则直接行内编辑。这种碎片化的交互让用户体验极差。整合之后我确立了统一的交互规范：所有的编辑变为单元格点击编辑，不再自定义交互，彻底消除了体验的割裂感。

2. 优化：Zuo减法，提效率

“优化”是在整合的基础上，对现有逻辑Zuo“减法”和“提效”，核心是消除冗余代码、提升性Neng和开发效率，而不是简单地堆砌新功Neng。

冗余逻辑从何而来？根据我的经验，所有类似“这段逻辑先留着，以后可Neng会用到”、“老的逻辑别删，加一个新的就好”的话术，本质上dou是开发过程中的偷懒。这种不想花时间理解前后业务逻辑的心态，将所有的不确定性留在了代码中，随之而来的就是高昂的技术债务成本。

3. 重构：小步快跑，规避风险

重构不是“大爆炸”式的推倒重来而是“小步迭代”式的升级。简单来说模块化是“拆逻辑”，将复杂功Neng拆分为独立的逻辑单元；组件化是“拆UI”，将页面拆分为独立的UI单元。

在实践过程中，我对这两个概念有了新的认知。比如我有一个复杂的表单页面涉及两个表单和多个动态表格。虽然按理说Ke以写到一个 vue 文件中，但这会导致单个文件代码量飙升，维护起来让人抓狂。geng糟糕的是这会形成一种惯性：“之前dou这么写的，我再往后面加就行。”

边界重构的核心在于拆分“职责混乱”的模块。就像玩俄罗斯方块，每一个需求就是一个下落的方块，把它落在哪个地方，如何与Yi有的方块贴合，或者给未来的方块腾出空间，决定了这个游戏Neng玩多久。

三、 技术落地：从组件封装到架构升级 1. 组件的极致封装：useLog 的进化

以日志弹窗为例，旧系统中到处dou是重复的弹窗逻辑。在重构的视角下我们需要从全局角度所有场景的通用性，抽象出“通用日志弹窗组件 + useLog Hook”，把“日志类型、数据结构”等作为参数，让所有日志弹窗复用同一套逻辑。

Zui初，我们可Neng只是简单地引入组件：

虽然 vben5 Yi经对弹窗有了hen好的封装，但我们依然需要在页面结构中引入组件。为了极致简化，我写了一个 hook 进行二次封装：

import type { ExtendedModalApi } from '@vben/common-ui';
import { h, render } from 'vue';
import { useVbenModal } from '@vben/common-ui';
import Log from './Log.vue';
export function useLog: {
  LogModalApi: {
    open: (data: {
      /** 日志类型 */
      logType: number;
      /** 日志对象参数 */
      objectId?: number | string;
    }) => void;
  };
} {
  let container: HTMLElement | null = null;
  let currentModalApi: ExtendedModalApi | null = null;
  const createModal =  => {
    if  {
      render;
      container.remove;
    }
    container = document.createElement;
    container.setAttribute;
    document.body.append;
    const  = useVbenModal({
      connectedComponent: Log,
      onClosed:  => {
        if  {
          render;
          container.remove;
        }
        container = null;
        currentModalApi = null;
      },
    });
    const Node = h;
    render;
    return ModalApi;
  };
  return {
    LogModalApi: {
      open:  => {
        currentModalApi = createModal;
        currentModalApi.setData.open;
      },
    },
  };
}

经过这样的封装，调用方式变得异常清爽：

这不仅精简了业务页面的代码量，也让“整合后的Neng力”geng易用，避免了“整合后反而增加开发成本”的尴尬。

2. 表格编辑的抽象：从简单到复杂

在重构过程中，我发现处理表格内编辑缺省值的情况非常多。一开始，我可Neng只是简单地在 slot 里写逻辑：

后来随着场景增多，我意识到需要处理数字、布尔值、下拉选择等多种类型。经过几次完善，组件Zui终演变成了一个通用的单元格编辑器：

这种边界重构的实现，本质上就是组件化。在开发中不断回头发现Ke以整合优化的地方，就像玩俄罗斯方块一样把它们放在一排，然后就Ke以安心消除了。

3. 架构升级：Monorepo 与环境管理

我Zui喜欢 vben5 的地方在于它完美实现了 monorepo 架构。场景化拆分解决了中后台项目重复封装通用Neng力的痛点。所有非业务的代码douKe以放在 packages 中，项目代码对通用Neng力的调用就如同引用一个三方库。这让我的重构思路geng加清晰：如何将一个业务通用Neng力抽象为一个框架通用Neng力。

在环境管理方面公司项目的环境配置极其复杂：三个大环境，每个大环境下又有测试、预发、生产三个小环境。这意味着一个项目有九个环境。之前的运作方式是三个大环境三个 git 仓库，每次完成需求dou要对另外两个仓库进行代码同步，工作成本基本翻倍。

重构后我采用了 vben5 的 dotenv 方案。通过 import.meta.env.xxx 访问环境变量，不同环境的差异代码变得非常清晰：

对应的 .env 配置如下：

#.env.production.yc
VITE_GLOB_APP_BUILD_TYPE=product
# 环境常量
VITE_PAGE_TITLE=医疗后台-银川
VITE_PAGE_DESC=欢迎登录银川医疗后台！
#.env.production.nj
VITE_GLOB_APP_BUILD_TYPE=product
# 环境常量
VITE_PAGE_TITLE=医疗后台-南京
VITE_PAGE_DESC=欢迎登录南京医疗后台！

结合 Docker 部署，只需在 Dockerfile 中指定对应的 build 指令即可完成自动化部署。这套流程对于日常开发来说非常省事，且多环境可拓展性极强。

四、 价值重塑：从代码搬运工到业务架构师

作为一名前端开发，Ru果还只注重功Neng实现，那么被取代或许真的不远了。Linux 基金会的报告指出，AI正在重塑工作，而非消灭工作。这深刻改变着人才需求格局。

1. 理解业务是技术的护城河

处理日常问题只是业务Neng力的基础。通过深度理解业务，将业务问题转化为技术问题，用技术手段实现业务目标，这才是核心价值。这要求我们具备技术前瞻性，Neng够预判技术趋势对业务的影响。

有一次业务同事吐槽配置一个营销策略花了将近一下午。虽然逻辑不复杂，但操作极其繁琐。从那以后我在Zuo表单类需求时dou会潜意识考虑：除了完成功Neng，它到底好不好用？

在重构中，我将所有涉及复杂表单的场景进行了彻底的交互重构。原来需要两三个弹窗完成的配置，全部设计成Zui多一个弹窗搞定。这印证了UX领域的经典原则：“把复杂留给自己，把简单留给用户”。表单体验的好坏，本质是开发者Neng否把复杂的业务逻辑转化为用户可感知的简单交互。

2. 情绪价值与协作共赢

研发价值的Zui高阶段，是有了前两阶段沉淀后的协作共赢。Zui优实现方案往往不是“技术Zui优”，而是“业务价值、研发成本、时间周期”三者平衡的全局Zui优方案。

“情绪价值”的核心是对齐预期、降低协作摩擦。比如产品提了一个复杂需求，研发不是直接说“Zuo不了”，而是说“这个需求Ke以拆成两步，第一步先实现核心功Neng，成本低、见效快，第二步再优化体验”。这既提供了情绪价值，又给出了可行方案。

3. 前端的核心价值：交互与渲染

前端应当从“功Neng实现导向”转向“用户体验 + 工程效率双导向”。前端的核心价值是“交互和渲染”，而非“数据结构的二次重构”。过度的前端数据处理属于“无效的技术成本”。

hen多时候，后端返回的数据结构不是我们想要的。Ru果我们在前端Zuo大量的数据适配，就会埋下可维护性的坑。这时候，前端中间层 的必要性就呼之欲出了。把数据结构适配的成本从前端代码层转移到前后端协商层，既不用后端改变固有设计，也不用前端二次开发。当然这需要根据实际工作环境权衡成本。

五、 ：在不确定性中寻找秩序

hen多人认为Zuo业务开发缺乏挑战性，其实正好相反。Zui难解决的Bug是无法重现的Bug，Zui难处理的问题域是不确定性的问题域。业务往往是Zui复杂的，面向不确定性设计才是Zui复杂的设计。

软件工程学科Zui难的事情是抽象，因为它没有标准、没有方法、甚至没有对错。如何在软件固有的复杂性上找到一条既不过度也不缺失的路，是软件工程师的终身课题。

这半年的重构，让我明白了一个道理：需求迭代不应是功Neng的简单堆砌，而是功Neng的不断整合。我们必须从“被动接需求”变为“主动Zuo治理”。通过整合、优化、重构，让代码体系随需求增长geng有序而非geng臃肿。

正如《人月神话》中所言，这个行业需要我们掌握geng先进的开发要素和工具，经论证的管理方法和Zui佳应用，良好判断的自由发挥，以及保持谦卑。

系统重生了而我也在代码的废墟与重建中，找到了新的方向。

---