2023 年技术小结：从前端工程到 AI 应用

wuwenzen@outlook.com (wuwj) — Wed, 20 Dec 2023 00:00:00 +0000

如果用一句话概括 2023 年的技术主线，大概是：

一边继续把前端工程体系打磨扎实，一边认真把 AI 接到「真业务」里。

这一年做了几件印象比较深的事情：

把多个前端项目合到 Monorepo；
尝试微前端，把老系统和新模块串起来；
在中台里跑了几轮完整的 A/B 实验；
接入大模型 API，做了文档问答、内部工具智能化的小应用；
把 AI 真正纳入自己的日常开发流程。

这篇总结就按这两条主线——前端工程 和 AI 应用 来回顾一下。

1. 前端工程线：更「稳」也更「合在一起」

1.1 Monorepo 落地

年初开始，把几个关联度高的中台项目合进一个 Monorepo：

tools：pnpm + Turborepo；
结构：apps/ + packages/；
公共库：UI 组件、工具函数、统一 ESLint 配置。

收益：

组件库和工具修一次，多项目同步升级；
工程规范「一处改，全员受益」；
新项目孵化成本明显降低。

也逼着自己思考：「什么才值得抽成库，什么就留在应用里？」
这对边界感的训练很有帮助。

1.2 微前端小规模应用

不是全线切微前端，而是谨慎选择了几块：

老 Vue2 中台 + 新 Vue3 模块；
部分实验性应用用 React 写。

用「框架型微前端」把它们挂在一个壳子下：

主应用管登录、导航、全局样式；
子应用各自管内部路由和业务。

实践下来感受是：

在「多团队 + 多技术栈 + 独立发布」场景下确实好用；
但也确实增加了复杂度，需要配套工程规范。

1.3 实验和监控：让前端更「可观测」

这一年比较系统地做了两件事：

从 jQuery 到模块化：一次前端工程意识的转变

wuwenzen@outlook.com (wuwj) — Fri, 20 Dec 2019 00:00:00 +0000

背景

在较早阶段的前端开发中，常见技术栈以 jQuery + 传统页面结构 为主。
这种模式在页面数量有限、业务逻辑简单时，具备实现成本低、交付速度快的优势。

但随着功能逐步增多、页面之间产生联动，代码结构问题开始显现，对可维护性提出了更高要求。

传统写法暴露的问题

1. 全局作用域污染

var list = [];
function init() {}
function render() {}

常见问题包括：

变量与函数暴露在全局作用域
多页面脚本容易互相覆盖
问题定位与调试成本逐渐升高

2. 文件职责混乱

在缺乏结构约束的情况下：

单个 JS 文件体积不断膨胀
DOM 操作、业务逻辑、接口请求混杂
修改局部逻辑时容易产生连锁影响

3. 代码复用能力弱

相似功能在不同页面中往往通过复制实现：

复制后再做细微修改
长期来看难以统一维护
Bug 修复成本被成倍放大

引入模块化思路

为缓解上述问题，开始尝试在不依赖复杂工具链的前提下，引入基础的模块化设计思想。

1. 按职责拆分代码结构

js/
├── api.js
├── render.js
├── event.js
└── main.js

通过人为约定实现基础分层：

接口请求集中管理
渲染逻辑独立拆分
事件绑定避免分散在各处

即使不依赖构建工具，也能显著提升代码可读性。

2. 使用 IIFE 隔离作用域

(function () {
  var state = {};
  function init() {}
  window.pageInit = init;
})();

这种方式在早期用于：

前端工程化 on Saiga