【前端技术分享】前端技术改造踩坑心得分享

掌门教育前端技术分享会第一期已于1.23号落幕，如下为大咖讲师们现场演讲的整理稿，感谢你们的支持：

讲师介绍

程波，前端技术架构师，来自掌门教育业务系统团队

如下为程波同窗精彩演讲的部份内容：

大前端时代，前端技术架构设计

我最开始工做的时候，加入的部门是UED团队，整个团队接近30号人，其中绝大部分同窗是作交互、页面设计的，写代码的同窗只有10个左右；咱们这10我的里，只有2个是写JS代码的，其它人都是写HTML、CSS的；工做流程方面，我把设计稿转化为HTML、CSS代码后，交给JS开发同窗，帮咱们添加弹框、banner轮播等等交互特效，打包成zip包发给PHP团队，以后全部的业务数据集成、部署、监控等等都跟咱们没有关系；

为何之前的工做内容这么局限、狭窄？我简单猜想一下，大概以下几点：

1. 电子设备不普及，绝大多数人一天里面也碰不到几回电脑、笔记本
2. 当时上午是一件很贵的事情，网速又很慢，体验很是差
3. 社会互联网文化氛围几乎没有，大数据、可视化、信息化等等，这些咱们如今认为企业必备的概念，那个时候一片空白
   总而言之，前端开发缺失具体的业务实现场景

如今，彻底不同，是前端业务场景百花齐放的时代，我以前有一次去商场吃饭，在自动扶梯旁看到有一个立式楼层指示牌，我就上去滑动屏幕，想看看4楼有什么门店，划了二、3秒，屏幕都没动，我当时很是奇怪，以为屏幕是否是坏了，后来才发现这个屏幕就是固定的，闹了一个笑话；

后来，我就思考，为何我会以为屏幕不动，就是屏幕坏了？答案其实很简单，由于我以为任何我能看到亮的屏幕，它就应该能被交互才对；

因此，如今是前端的美好时代，由于咱们的业务场景很是很是多！

大前端时代，咱们对前端技术架构的要求更高

一我的作项目，跟100我的作项目，团队对工程化的要求确定是不同的；作一个项目，跟同时作100个需求，团队对自动化的要求确定也是不同的；之前咱们前端产出的产品只有百来我的、几千人、几万人用，如今咱们前端项目上线，可能会面临几百亿、上千亿、上万亿的流量，这对咱们的监控、预警等等也提出来更高的要求；这样的种种要求还有不少

也由于以上种种缘由，在这个时代，团队、公司对于前端工程师的要求，也不只仅是会写H5页面、作交互就OK了；如今前端涉及的领域愈来愈广，对开发人员的素质能力要求也愈来愈高，这是一个更多场景赋能，动力、压力并存的时代

咱们前端的技术架构设计图

这张图越往上越靠近业务，越往下越靠近支撑，右侧则是对整个生命周期的监控，我着重描述一下【环境管理】、【集群管理】、【监控管理】：

环境管理：之前咱们团队作过一个微信公众号的需求，公众号开发流程你们或多或少都有所了解，微信给咱们一个key、secret，咱们拿这两个字段去换token，而后缓存下来，业务场景里面，咱们带上token去拿用户的信息数据；当时咱们团队只有一个测试微信号，可是有不少套测试环境，每一套测试环境都是互斥、隔离的，但在微信这种场景下，当A、B测试同窗同时作测试的时候，就会形成token反复申请，服务请求互踢，最终致使资源耗尽，这种体验就很是差，相似的场景还有不少，好比redis、DB等等，这就是环境管理的问题

集群管理：201五、16年的时候，咱们作过一个整点秒杀的需求，天天中午12点、晚上19点作活动，时间只持续半个小时，当时阿里云尚未提供快速扩容、快速释放功能，说人话就是，12:00借100台机器，12:30还，抱歉不支持；而咱们的后端由于种种缘由，也不太好作秒杀需求，后来我跟我老板说，前端来实现这个功能，咱们开发完提交测试，测试也经过了，功能没有任何问题，而后咱们的运维开发同窗过来跟我说，咱们秒杀场景大概20W左右的QPS，前端须要报备多少台ECS？当时我就懵了，由于我当时对服务器负载一点概念都没有，后来咱们紧急作了压测，大概须要大十几台4C8G的ECS，这就一个集群管理的问题

监控管理：去年11月份的时候，咱们的产品经理跟咱们提了一个购物车的需求，当时是PC、移动端两版实现，工做量仍是很是大的，而后咱们开发小伙伴过来找我，问我能不能跟产品沟通一下，不作IE的支持，我跟小伙伴说没有问题，后来我找咱们的运维同窗，问他能不能帮我拉一下生产的流量数据，数据拿到后，咱们看了一下，移动端大概95%的流量，PC端5%左右，并且PC端几乎没有来自IE的流量，我把数据整理了一下，发给产品，表态咱们不作IE的支持，这就很是有理有据

为何咱们要作技改

咱们团队如今手上的项目，有一些已经有3-5年的历史了，实际上是很是很差作技术改造的，为何咱们要立专项作技改呢？我问了本身几个问题

1. 咱们如今的一些项目，变量config、接口请求代理、开发依赖、运行时依赖等等风格迥异，若是项目紧急，多人协做开发，经过看历史备注，咱们可否实现非干系开发同窗无缝、快速上手开发？
2. 对比前面咱们设计的前端技术架构图，若是咱们在最前置应用层部分项目，不作集中性改造，将来环境变量管理、ECS集群管理、监控这一块，隐性成本是否可控？
3. 若是这些项目的技术改造，不立专项作，放在业务需求里面作，是否可行？
4. 咱们能不能容忍团队技术落后？

这几个问题一出来，咱们就以为确定是要立专项作技术改造了

技术改造踩坑

踩坑一：想法太多，技术改造步子迈太大，Hold不住！

一开始，咱们作的技术改造范围很大，开发花了很长时间进去作优化，提测后，测试同窗也发不少的样式bug回来，由于历史业务细节太多了，全量作风险实在过高，最后咱们没有办法，把这一部分的代码都回归了；第二个项目技改的时候，咱们就给本身定下来MVP原则（最小价值实现），围绕咱们前面的技术架构设计图，设计标准目标，而后只作这构建、环境管理、api代理、依赖库统一等等几个目标的实现，其它问题，咱们适当放到业务需求里面去作

踩坑二：为了技改而技改，项目技改完成，人力也浪费了

咱们中间有一个项目作技术改造的时候，测试资源很是紧张，提测后，几乎就是压着先后两个需求发布计划来作回归验证的，后来这个项目成功上线，可是尴尬的是，此后这个项目就没有大的需求过来，前段时间我去看了一下这个项目的发版记录，技改后只有一个优化需求上线；这就是咱们在作技术改造前，项目背景、业务需求紧急度，开发频次等等调研不够细致形成的

关联方沟通不到位，不关注业务价值，没人验收

在作技改方案设计的时候，我其实还挺以为咱们方案颗粒度作得真好，业务、开发、验收方各司其职，结果就踩了一个大坑，咱们财务系统技改发布的时候，测试已经跑通UAT环境，代码也合到了master分支里面，咱们急急忙忙把产品同窗拉到咱们的技改群里面，但愿他作验收，产品同窗表示：如今这个点上，他不作验收；我过去跟咱们产品同窗沟通，但愿说服他作验收，聊下来，我发现咱们产品同窗是对的，由于12月份是咱们公司的销售大月，而已由于是年末，这是一个超级大月，提早半个月上或者晚半个月上都没问题，但这个点上确实风险比较大；后来这个项目的技改延期了20+天，中间又由于一部分业务需求的迭代，出现了部分代码冲突，实际上，咱们算下来，形成了4人天左右资源浪费；技改一方面是为了知足咱们前端技术团队本身的需求，同时，业务需求、业务保障更是咱们最重要、最核心价值之一

技术改造，不止于技术

10月中下旬，咱们刚开始作技改方案的时候，咱们一直在想，要不要上webpack五、甚至开玩笑上Vue3.0等等，此次技改怎么样才可以体现咱们技术的高大上，另一方面，咱们又常常吐槽过去这些项目的技术设计作得很差

但后来，我仔细思考了一番，我发现这种认知偏见是不太准确的，这里有一个幸存者误差，咱们部门过去这几年，作过的项目确定不止咱们如今技改的七、8个项目的，甚至咱们吐槽最多的老项目，其实也只占咱们技更名额的3-4个，咱们如今团队有50+项目，历史项目只会更多，其它项目哪里去了呢？由于没有需求迭代了，或者业务被下掉了，全部不少业务代码是跟着公司阶段性目标，定制化实现的，好像问题也不大

我另一个非技术性的思考是，技术改造是一个将会反复持续的过程，随着业务迭代、技术演化、时间不断前进，再过3年、5年，特别是前端领域，技术改造又会是一个轮回；因此咱们此次的技改实现，关注底层支撑，好比环境变量规范、api请求规范、构建规范、依赖库规范、流量灰度，日志监控等等

咱们常常形容技术改造，是在火箭行进过程当中换零件，换零件确实是一件艺高人胆大的活，但它的前提条件是火箭至少还能飞、还能被改造，这里其实就要求火箭自己的质量自己要过硬才行，因此这一次技术改造，咱们很是关注支撑这一层，也就是这个缘由

感谢阅读，更多精彩内容，欢迎关注咱们掌门教育前端技术