spxiaomin / markdown-resume-template

BAT程序员自己的简历模板分享出来了 。技术简历追求简单明了，避免没有必要的花哨修饰，大家可以fork到自己仓库中，基于这个模板进行修改。

谷俊民个人简历

个人信息

• 性 别：男             年 龄：27
• 手 机：15900948714         邮 箱：[email protected]
• 专 业：湖南科技大学2018届信息安全专业、本科    岗 位：资深Web前端/前端专家

工作经历

• 莉莉丝       2021.3~至今          中台产品部门
• 字节跳动      2019.4~2021.3         商业化部门
• 饿了么       2017.12~2019.4        C端外卖平台

自我介绍

• 熟练使用React、Nodejs等前端技术栈进行全栈产品架构设计和开发.
• 可以良好地使用Golang，并使用其开发和维护服务端项目，对分布式、高并发等略有经验.
• 较丰富的面试官经验和小型团队管理经验(5人以下)、开发&发布等流程规范制定、团队氛围、分享等.
• 较强的自驱力和团队协作精神.

项目经历

莉莉丝

1. PSP「莉莉丝客服系统,从0-1」- 2021.3-至今

   • 背景&目标
     • 该项目用于整个公司内部的游戏客服服务，解决客服团队、游戏、玩家之间的沟通问题对接.
     • 节约每年数百万的客服系统购买费用.
     • 链接内部多个部门间的系统，打通内部知识库，物料反哺用于AI等.
   • 角色&责任
     • 系统负责人「3-5人」.
     • 负责项目的从0到1的技术调研、业务迭代维护和技术发展选型.
   • 项目挑战
     • 技术调研 & 落地.
       • 项目初期定位是服务于客服的中大型后台系统，涵盖C端客服会话、B端客服系统、分配、知识库等一切链接客服、游戏、玩家的系统.
       • 基于项目的定位，必然是大而全且需要长期迭代维护的系统，那么必然需要做好系统的解藕，“微前端”因此成为了技术的首选.
         • 技术方案的抉择倒是相当明确，基本没有比qiankun更流行和完善的方案.
         • 从项目整体的组织方式「mono-repo」、到qiankun父子应用的组合、通信、发布等进行了从0到1的尝试，并合运维团队密切配合，落地了此方案.
         • 经过多年的时间验证，也证明了此方案的正确.
       • 带来的效益.
         • 「团队提效」微前端带来的好处，就是不同业务线开发的同学开发互不干扰「定好统一的团队规范」，达到人效1 + 1 = 2.
         • 绝对的架构上的解藕，开发和发布独立. 但是最终呈现在一个产品中.
     • 通信会话.
       • 整个系统最核心的就是通信协议的制定，从登录态、消息发送、重试、指数避退、消息的拼配组合、可靠性、心跳等，和后端、产品同学反复沟通、推理，并最终落地.
       • 技术方案的选择采用的是ws + proto的方式，双向通信且高效、体积小.
       • 整体的通信层和应用层抽离，提升并行开发效率.
       • 整体的架构重新设计「从单hook -> 基于context的多hook数据分发」，避免单体文件过大，提升可维护性和提高质量.
       • 200+工单性能优化问题排查「数据量大，react17不会在event callback中缓存更新，大量DFS遍历」，性能优化消耗30+s → 700+ms.
     • 权限系统.
       • 公司内部采购了统一的认证平台，但是对于权限系统的使用过于复杂，因为在认证平台的基础上，重新基于RBAC模型进行了新系统的设计和落地.
       • 权限数据对于各个子系统的分发方案设计和开发.
     • 双子应用/工具集.
       • 对于整个系统而言，存在多块业务，因此势必存在多个系统之间的共通功能，因此需要在系统的旁侧提供第二系统.
       • 与此同时，系统已经迭代维护了2年，技术栈略微老旧，为了保证系统的技术更新迭代，复用了umi对于qiankun的现有通信逻辑，但升级了新版本v3->v4.
       • 并对于新系统剥离了mono-repo结构，独立自己的项目仓库，提供系统的可维护性和技术可扩展性.「e.g. 对于mono-repo而言，从yarn换到pnpm都是巨大的QA成本」

2. 内容管理平台「低代码」2022.3-2023.3

   • 背景&目标
     • 在公司内部会有多种渠道进行玩家的触达，e.g. 短信、邮件、电话等，对于其中发送的内容需要进行统一的管理，并集合触达平台进行相关的发送.
     • 节约每年数百万的外包开发成本.
   • 角色&责任
     • 内容管理平台的架构，分工.「可以作为微前端子应用，也可以iframe集成」
     • 低代码邮件编辑器从0到1的设计 & 架构 & 开发.
   • 项目挑战
     • 低代码邮件编辑器的设计.
       • DSL设计 + 平台搭建 + 画布交互开发 + 元素属性编辑.
       • 富文本的集成TinyMCE.
       • 发行团队对于多游戏的邮件在多端的渲染兼容处理.
         • 白线问题、布局错位.
         • 图片过多性能卡顿.
         • 背景图暗黑模式反色等.
     • 内容管理平台的集成方案.
       • 公司内部当时对于微前端的方案没有那么普及，需要考虑其他平台对于此模块的集成.
       • 采用runtime判断当前所处环境，如果在微前端中就采用对应的钩子通信并处理相关逻辑，如果在iframe嵌入集成那就通过postMessage进行通信并处理相关逻辑.
     • 跨团队的沟通和协调.
       • 当时此项目涉及到两个部门、3个团队的协作，对于责任心和细节、沟通等极为考验.
         • 明确时间节点.
         • 推理和完善并对齐技术细节，有owner意识.

3. Gear服务中台「Nodejs全栈」2023.3-至今

   • 背景&目标
     • 当前所在部门是中台部门，存在很多通用中台服务，那么对于其中台服务的接入需要一个统一的管理后台，于是便诞生了此项目.
   • 角色&责任
     • 负责系统的架构设计&迭代、任务分工.
   • 项目挑战
     • 技术选型.
       • 基于开发效率高、并发要求不高的特点，Nodejs很快就成为了首选.
       • 其中节省了前后端的对接&沟通等时间.
       • 并且能够提升同学对于业务的把控能力，进而能够从技术的角度去对产品查漏补缺.
     • 技术栈的更新迭代.
       • 最初前端采用的是一体的方式，没有微前端，因此在技术迭代之后，很难对现有项目进行更新.
       • 当项目本身是一个“微前端”架子，最外层的基座+各个不相关的后台.
         • 因此采用最小成本重构了最外层的架子，而后对于老应用采用iframe的方式进行嵌入，对于老数据等采用localStorage&postMessage方式进行处理.
       • 采用此方式后，以极小的开发成本就可以对于新的“后台”采用更新的技术栈&更高的效率开发.
     • Nodejs后台服务分流.
       • 对于Nodejs服务存在同样的问题，本身Nodejs更新迭代比较快，再加上此系统经过多人之手，代码略微显的可读性不强，维护成本增强.
       • 采用Nginx服务分流，搭建一套全新的Nodejs服务，对于老旧的业务根据ROI需求看是重新开发or继续在老项目上迭代.

4. FAU静态资源服务「Golang&go-zero」2023.3-至今

   • 背景&目标
     • IM/社区等C端用户都有上传静态资源的诉求.
     • B端内部后台也有相关的需求.
     • 为了减少项目接入方的接入成本，于是对于Aliyun oss/AWS/Google Cloud进行了封装，提供了Policy方式进行上传，并提供了对应的CDN URL进行访问.
   • 角色&责任
     • 项目负责人.
     • 项目的开发&迭代.
     • 游戏项目方的接入.
   • 项目挑战
     • 安全方案设计.
       • C端接口设计的鉴权方式是采用token检验，因此导致只要在用户上传正确的token的情况下，就可以任意盗用我们的接口进行上传，进而滥用我们的CDN资源.
       • 因此采用了如下的方式进行减缓.
         • 用户级别的单接口限流「令牌桶」.
         • 服务监控 & 手动拉黑.
         • 上传体积限制.
     • 前端站点.
       • 对于内部的运营同学等，都会有上传诉求，单单通过后台接口的方式，很足不了诉求. 以及对于其他的前端平台等，也不是特别方案进行接口接入.
       • 因此需要提供前端站点的方式进行使用和接入.
       • B端采用的是签名的方式进行鉴权，只有获取到sign的服务方可上传.

5. Lilith公司私有源站「开发&维护, Nodejs&Golang」2021.3-至今

   • 背景&目标
     • 公司内部共有组件的私有化诉求.
     • 团队内部跨项目的代码共享.
   • 角色&责任
     • 项目负责人.
     • 日常常规维护和问题支持.
   • 项目挑战
     • 公司级别统一.
       • 对于初期而言，跨团队的沟通，和命名规范等的对齐，以及各个团队OKR的对齐等都是比较考验协调能力的.
       • 技术选型还是比较明确，CNPM的维护和部署都有完善的支持.
     • 项目部署.
       • 因为项目基本改动不是特别频繁，采用单机Docker部署，降低成本.
       • NPM包本地文件存储，运维定期24小时快照一次，保障服务安全.
       • 白名单限制访问.
     • Party Npm源仓库包迁移方案调研 & 开发.
       • 公司内部存在极大的包，会超过Nodejs内部MAX_STRING_SIZE的限制，因此无法通过npm publish上传.
       • 因为开发了内部的sync接口，先讲文件传至oss，然后在nodejs内部采用stream进行文件下载和表更新.

6. 其他

   • 前端系统.
     • 大会员C端/公告系统/身份验证后台&C端/扫码登陆C端/大R后台/Parkway配置后台/官网/协议后台等.
   • 后台服务「Golang」.
     • 外呼系统/权限系统等.

字节跳动

1. 图片编辑「1年+」

   • 背景&目标
     • 目前，字节主要的商业模式是多边商业模式——通过补贴创作者创造有趣、有价值的信息吸引流量，然后通过广告变现. 因为降低成本对公司来说是很重要的.
     • 在公司内部，按照之前的模式，每新建一个广告，至少需要一个设计师来设计相应的广告投放图片. 随着越来越多地广告被创建，需要更多设计师. 除此之外，设计师的成本不是线性的，因为需要有管理成本和沟通成本.
     • 因此就产生了这个项目. 项目有两个产品线. 一是图片效果增强，就是在广告主提供了投放图片的情况下，为其添加特效，辅助其提高转化率. 另一个是AI图片，广告主可以根据选项进行相应的输入，然后会产出多张图片给广告主，广告主后续可以在编辑生态工具进行编辑.
   • 角色&责任
     • 负责图片编辑工具生态的建设.
     • 支持更多的业务线.
     • 完善编辑生态.
   • 项目挑战
     • Iframe 简化编辑器
       • 各种系统需要图片编辑画板，但是不需要其他的复杂编辑模块. 以及想把其集成到自己的系统中去. 因为我将图片编辑画板进行了拆分，成为一个独立的组件复用，然后以iframe形式进行导出. 其他系统通过iframe api进行沟通.
     • 可配置编辑能力
       • 对于线上图片编辑系统，需要支持较多的业务线进行图片编辑. 因此如果代码未进行良好设计，会是一团糟. 总体来说，系统主要两块，一是编辑器，二是业务. 不同业务需要不同编辑功能. 于是通过将编辑器单独抽离一层，然后通过参数进行控制.
     • 图片渲染
       • 这是线上编辑生态的核心部分. 一般来说，总共4个渲染方法，svg to image/canvas to image/puppeteer/render engine like webkit. 我初步选择了puppeteer方案，因为是个后端方案，可以在多个系统被使用到，并且具备较好地可扩展性. 但是这个方法是低性能地，4台 4g/8core的服务器，qps才40. 因此，与此同时在尝试将webkit中渲染部分抽离，但是由于业务调整，项目被交到其他项目去了.

2. 广告联盟转化卡「0.5年+」

   • 背景&目标
     • 公司存在一定量的第三方流量，因此公司通过了一个sdk的方式帮助第三方流量进行变现，项目的目的是提供一个平台用于管理和编辑广告样式.
     • 项目存在两个系统，一个是管理样式，一个是用于编辑样式以及webview h5渲染.
   • 角色&责任
     • 参与编辑部分开发，提供广告需要的编辑组件.
     • 负责h5渲染的UI自动化探索. 这部分存在的原因是QA开发的资源不够，以及每次h5渲染引擎改变的时候都要手动进行线上样式渲染检测，非常耗费不必要人力资源. 后期采用了appium + node.js报告服务的方式进行了解决，但是后续QA开发资源恢复，因此将项目交回了QA侧.
   • 项目挑战
     • 项目最具挑战性地就是UI自动化从0到1的探索，因为在这之前，我没有任何经验. 解决问题最关键地就是耐心，不断搜索/学习/实验.

3. 编辑中台「4月+，初期是上海和北京合作开发，后期由于团队调整，交予北京」

   • 背景&目标
     • 项目中存在非常多业务相关的项目，每次都要重复进行编辑能力地开发，因此非常必要进行编辑部分的复用抽离.
     • 技术方案: 编辑器的每一部分都是组件，可以进行任意业务需求组合. 通过一个core.js进行通信「tapable.js」. 每一个组件可以通过配置进行扩展.
   • 角色&责任
     • 项目整体的架构设计.
     • 业务支持.
   • 项目挑战
     • 项目更多是编辑开发经验的抽象，不具备太大挑战.

饿了么

1. C端外卖平台业务「1.5年」

   • 背景&目标
     • 在当时是一个移动为王的时代，饿了么作为当时的一个外卖巨头之一，对于具体的流量需要一个呈现形式，那么移动H5页面就成了一个开发必须项.
   • 角色&责任
     • 日常外卖活动业务的H5开发.
     • 大会员等系统的日常开发迭代维护.
     • 新同学带领.
   • 项目挑战
     • 流量大.
       • 当时每日可达到平均100万到1000万的DAU，一旦一点点的小bug就会被无数倍方案.
       • 对于代码逻辑、Code Review、QA测试等要求及其严格.
       • 服务监控等力度把控要求高.
     • 性能要求高.
       • 为了达到秒开的性能体验，从inline-script、雪碧图、压缩、合并、异步、CDN加速等一一都做了累加，然后通过监控服务进行一点点的数据验证.

2. B端保险商户业务「1年」

   • 背景&目标
     • 商户的食品安全和保险购置，用户的保险理赔等都是一个外卖平台不可或缺的一环.
     • 因此从理赔C端入口、到理赔管理后台、商户保险管理后台等都需要一套完善的产品.
   • 角色&责任
     • 理赔C端入口的开发&迭代维护.
     • 管理后台的日常开发&迭代维护.
   • 项目挑战
     • 和如上的C端外卖平台业务一致.

个人账号

• github 地址 https://github.com/SPxiaomin

最后

感谢您花费宝贵的时间阅读完我的简历，期待和您共事.