前端架构 / 基础建设简历范本

个人优势

• 8 年前端经验，近 4 年专注多团队共用的构建、组件和质量基础设施，服务 20 多个业务团队
• 平台建设先找业务阻力再定能力边界，用接入率、构建耗时和故障率衡量成果，而不是功能数量
• 做过从零到一的设计系统：语义 Token、亮暗与高对比主题、组件状态测试，接入后页面交付周期缩短约 25%
• 主导过多仓库到 pnpm Workspace 的迁移，先统一 lint、测试和发布元信息，再抽公共组件，不在一次迁移里同时换框架
• 熟悉构建性能治理：远程缓存、按变更范围构建、产物分析，大型仓库 CI 时间有过成倍下降
• 建立按业务级别配置的质量门禁，交易页要求关键路径冒烟，内部页面不强制同样的性能阈值
• 发布与回滚：Source Map 绑定版本、发布后自动对比错误人数和 LCP，资源缺失导致的回滚从每季度 6 次降到 1 次
• 写过 codemod 和 ESLint 规则推动大版本升级，提供兼容窗口，业务可以按风险分批迁移
• 带 5 人基础建设小组，负责规划、评审和对外支持，平台问题有值班和响应时效
• 保持对一线业务的感知，每季度轮岗参与一个业务需求，验证平台在真实场景里的体验
• 技术栈：TypeScript、Vite、Webpack、Rollup、pnpm Workspace、Turborepo、微前端、设计系统、CI/CD

工作经历

负责云控制台公共前端平台，控制台包含 30 多个产品域、约 70 名前端开发；我带 5 人小组维护构建、组件和监控体系。

• 构建平台：旧仓库一次全量构建平均 28 分钟，业务改一处文案也要等完整流水线。先按包依赖图拆任务，接入远程缓存与受影响包检测；缓存命中时 CI 中位耗时降到 8 分钟，未命中时仍能完整构建验证
• 组件治理：设计系统此前有 3 套 Button 和 4 套表格，升级成本高。和设计、无障碍、业务代表制定 Token 与组件 API，写 codemod 迁移常见调用；一年内核心组件在 21 个产品域接入，重复问题和视觉偏差显著减少
• 发布隔离：控制台多个产品共用一套入口，某产品静态资源错误会拖累整站。建立按产品发布的清单和资源版本锁，保留回滚入口；一次产品配置故障仅影响对应路由，未扩散到其他业务
• 监控标准：规定错误事件必须带产品域、版本、租户与 traceId，统一采集白屏和关键页面性能。告警按受影响用户数分级，线上问题由业务反馈后发现占比从六成降到两成以内
• 团队推广：用 RFC 说明迁移成本和例外情况，每两周与业务组复盘。没有要求一次性重写旧页面，先在新需求中采用，再按业务窗口迁存量；平台月活开发者超过 60 人

负责门店运营系统前端架构，团队从 6 人扩到 24 人，页面和仓库数量迅速增长。

• 将 11 个独立仓库迁入 pnpm Workspace，先统一 lint、测试和发布元信息，再抽公共业务组件；避免迁移初期同时改运行时框架和构建系统
• 给门店订单、库存等高频页面设置体积与 LCP 预算，超出后由负责人解释业务收益或给出拆包方案；典型低端设备 LCP 从 4 秒多降到约 2.5 秒
• 设计前端灰度开关，按门店与用户组放量，回滚只改配置；大促期间两次线上问题都在十分钟内回到稳定版本

项目经历

React / TypeScript / CSS Tokens / Storybook / Playwright

各产品线设计与代码实现长期分叉，用户在不同页面看到不同的表单和导航。目标是建立能被持续维护的共同语言。

• 先盘点 200 多个页面的交互模式，把表格筛选、权限提示和异步状态列为首批，不靠“换颜色”伪装成设计系统
• Token 区分语义与具体色值，亮暗主题和高对比模式使用同一套组件 API；表单字段按错误、警告、只读、加载等状态写测试
• 组件发布采用语义版本和变更说明，对破坏性更新提供 codemod；接入团队可以先替换低风险组件，业务高峰后再迁复杂表单
• 接入一年后，常见后台页面从设计验收到首次交付的平均周期缩短约 25%，组件缺陷由平台组集中修复

Node.js / GitLab CI / Lighthouse / Sentry

平台对每个前端项目提供同一套发布前证据：类型、单测、关键路径冒烟、包体积与性能趋势。

• 质量门禁按业务级别配置，交易页需要关键路径冒烟，内部低流量页不强制相同的性能阈值，避免一刀切拖慢团队
• 把 Source Map 上传与版本号绑定，Sentry 报错能对应到准确源码；发布后自动对比前后版本的错误人数和 LCP 分布
• 平台上线后，因静态资源缺失导致的回滚从季度 6 次降到 1 次；CI 耗时虽然增加约 2 分钟，但故障排查时间明显下降

pnpm Workspace / Turborepo / Rspack / Renovate

主仓库 60 多个包，全量构建 25 分钟，依赖版本各自为政，同一个日期库在产物里出现 4 个版本。

• 引入任务图和远程缓存，只构建受影响的包；构建工具从 Webpack 迁到 Rspack，保留插件兼容层逐步替换
• 用 Renovate 按分组自动提依赖升级 PR，配合构建产物分析标出重复依赖，半年内重复依赖减少约 七成
• 主仓库 CI 平均时间从 25 分钟降到 8 分钟左右，业务团队等待合并的时间明显缩短

教育经历