宋以衡

前端基础建设工程师 · 北京 · 8 年经验

songyiheng@example.com · 188 0000 0000 · github.com/songyiheng

个人优势

  • 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

工作经历

某云计算公司 · 前端基础建设负责人

2022.01 — 至今 · 北京

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

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

某零售科技公司 · 资深前端工程师

2018.07 — 2021.12 · 上海

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

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

项目经历

云控制台设计系统

2022.03 — 至今 · 某云计算公司 · 负责人

React / TypeScript / CSS Tokens / Storybook / Playwright

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

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

前端发布质量平台

2023.02 — 2024.03 · 某云计算公司 · 主导开发

Node.js / GitLab CI / Lighthouse / Sentry

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

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

前端构建加速与依赖治理

2020.03 — 2021.10 · 某零售科技公司 · 主导开发

pnpm Workspace / Turborepo / Rspack / Renovate

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

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

教育经历

北京邮电大学 · 软件工程

本科 · 2014.09 — 2018.06

常见问题

石板报头简历模板有什么特点?

石板灰报头线配 Inter 无衬线,姓名居中,列表是小方块。经典的报头结构配现代字体,克制又不老气,单栏结构招聘系统解析稳定,适合前端架构师。

石板报头适合什么样的人?

适合走招聘系统投递的前端架构师。

  • 大厂社招网申,简历会先过一遍解析系统
  • 负责过构建、质量门禁、发布系统的前端架构师
什么情况下不建议用石板报头?
  • 想用装饰体现个性的人,石板报头几乎没有装饰
用石板报头写简历要注意什么?
  • 架构类成果写使用方和推广情况,例如接入了多少团队
  • 石板灰小方块列表适合并列的能力项,每项一行最好
  • 技术栈放在个人优势最后,按构建、质量、发布分组
  • 报头下的双线已经分隔了抬头,个人优势直接写结论
可以直接在招聘网站上在线投递吗?

可以。这套是单栏阅读顺序,招聘系统能按顺序读出全部文字。

可以修改配色和简历内容吗?

可以。这套设计推荐 4 种配色,也可以自己取任意主题色;进入编辑器后,字体、字号、行距和模块间距都能单独调,简历内容随时可改。

下载的 Markdown 能自己编辑吗?

可以。下载的是完整的示例简历源码,可以在任意文本编辑器中修改;也可以直接使用本站编辑器导出 PDF。

相关模板

英文经典

居中抬头、通栏细线、斜体职位,外企和海外岗位的通行格式

紧凑一页

紧凑排版、个人优势和教育并排,经历多也能压进一页

简约黑白

最稳妥的选择,投大厂、走招聘系统都不出错

按岗位看完整范本

先看同方向的经历怎么写,再回到模板里调整版式。