一、客户的痛点问题，前端工作的价值点
1、前端的客户是谁
关于这个问题，一年前就有了一个相对完整的思考和概念，这一年下来变化没有太多。并且通过这一年的实践，对自己的这个答案有了更深层次的思考。
前端的用户包含有：
- 线上用户，无论是小b、大b、小c、或者是商家用户，凡是使用前端平台，使用前端系统功能的人，都是服务的一线用户
- 内部用户，包含我们公司内部的小二、客服、公关、产品、设计等等，满足业务产品的各类需求，做到快速响应以及上线后的稳定运行。其次，对于内部用户的工作效率，前端技术也需要承担一部分的责任
- 技术人员，包含前端、后端、移动端、测试、运维等等在内的所有参与研发的成员，涉及到研发效率、成本的问题，都可能需要借助前端的相关技术去解决
2、客户的问题是什么
- 对于线上用户，与前端技术最紧密相关的一个问题就是性能体验，他们希望更快的打开我们的应用，页面间切换更加顺滑，希望我们的页面更加漂亮，以及时不时的一些“啊哈时刻”给予惊喜
- 对于内部用户，他们最大的诉求简单来说，就是快速又稳定的项目上线，一是避免出现技术资源导致的业务响应不及时，使业务失去先机；二是线上应用的运行需要是稳定的，避免出现较大的故障，或者出现故障时很难快速恢复。对于效率这一块，好的交互体验方式，同样能够有效提高工作人效，进而降低成本
- 对于开发人员，研发效率和体验绝对是最大的用户诉求，大家都想投入最低的成本，获得最高的回报，任何简单、重复的操作都可能需要想着去进行工程化、自动化的优化。也只有这样，在紧张的业务节奏中才会有机会抽出部分精力，提升技术深度，关注业务领域的最新动向
3、前端能够做些什么
- 性能体验优化，利用各种技术或非技术手段，对用户体验和前端性能进行极致的优化。例如对小程序、H5的加载渲染速度做优化，对商家的后台功能交互体验做优化等等
- 提高工程化、自动化程度，一方面是为了提高效率，另一方面是避免人为操作造成的低级失误，避免进行大量重复无用工作。另一个方面，是对内部系统进行优化，例如对小二后台功能的移动化，提供一些快速查询的工具或者是浏览器插件等，甚至去业务一线轮岗，去发现业务同学实操过程中的各类问题
- 提高技术研发人效，确保业务代码高效产出，在保证业务诉求可以满足的基础上，尽可能使代码功能可复用，能够做到跨终端、跨业务线复用，不断完善中台化沉淀
关键字总结
性能体验、提效降本、稳定性
二、2021年的总结
1. 上半年主要做的事情
关键字：技术提效
前端技术中台化项目
项目目标：将业务和技术中通用的部分进行下沉，抽象出可复用的部分，将差异化内容改造成可配置插拔式的，使前端技术可以在多个终端、多个业务线间实现复用
根据公司业务特征和团队技术现状，尝试抽象出两个前端技术中台（容器中台、可视化中台）和两个前端业务中台（电商前台业务页面级应用、供应链业务中台）
前端团队用了近半年的时间，在这个几个领域快速做了尝试，虽然从结果来看，没有做到100%的成功，但是客观来说，已经很大程度上兑现了立项之初期望的效果，实现了技术的提效
其中，已经直接对业务起到明显促进作用的主要是两个：
1、容器中台
前端业务开发主要分布在多种容器场景，包含多个终端类型
- 微信App（微信小程序、微信公众号H5）
- 企微App（企微工作台H5）
- 内部自研App（原生App、内嵌H5）
这意味着在所有的终端上，因为开发语言及技术栈不同的缘故，我们要建设多种基建（包含开发者工具、代码规范、打包工具、部署工具、组件库、函数库等等一系列技术方案），而且开发一个业务例如CMS胶囊位，要开发多个语言多种代码（Android是Java，iOS是OC、小程序和H5是JS但存在大量不兼容语法需要处理），这样的开发成本显然是不符合快速高效低成本响应业务的初衷的，因此前端技术层面上的中台化势在必行。
通过在我们前端业务中的不断实践和踩坑，我们走出来一条相对而言比较适合我们业务场景的跨端技术方案：以Webview H5 Hybird混合型应用为主，部分React Native跨端原生渲染为辅的实现理念，在一定程度上抹平了跨终端的差异成本，提高了前端技术对业务的响应速度。
2021年我们在Webview H5容器技术基建上，与客户端团队合作，完善了我们的JS Bridge桥接库，使得更多的原生能力能够在H5开发中以统一标准的方式去调用，给业务提供更多的灵活度。在一级Tab的场景下，进行了容器预启动和资源预加载，使得此处内嵌的前端单页应用有着与原生App相媲美的体验。
我们在两个主要App工程中，新引入了React Native的容器基建，并且在业务中很快有了落地实践，在首页CMS活动资源位，我们只需开发一套React组件，编译出多端代码，在不同业务线和终端上实现了复用，做到了技术提效。综上，以Webview H5为主，RN为辅的跨端技术解决方案，足以满足解决我们业务绝大多数场景的问题。
2、电商前台业务页面级应用
目前电商前台业务中的订单、售后、客服、优惠券、地址管理等模块，已经做到了业务前后端的中台化收拢，可通过JSSDK + JSON配置化的方式，接入了多端多业务，过去需要n个人（安卓、iOS、前端H5、前端小程序、多个业务后端）开发的一次迭代，现在只需要两个人（中台前端、后端各一人）即可完成，很大程度上提高了业务的响应速度。
2、下半年主要做的事情
关键字：优化降本
1、性能&成本优化
下半年开始，得益于上半年技术提效带来的一些红利，使我们能腾出更多的精力在前端产品的性能体验优化上，当时是以阿里云资源成本的整体优化为契机，对前端所有的应用项目资源做了梳理。前端CDN资源主要以存储在OSS的JS、CSS、图片音视频资源为大头，还有少量的是字体、html文件和其他类型文件，优化的方向主要分两部分，一是资源请求的次数限制，二是有限的请求数还需控制体积大小。根据这个方向，前端具体需要落地的技术改动点也是比较显而易见，大概有以下几类：
- 代码JS、CSS资源进行更细粒度的拆分，过去比较粗的拆分是分为三大块（页面业务的js文件，业务公共代码的common.js，外部依赖的vender.js），进行细分后会变得更加精细，首先业务代码部分会按照单页应用的路由级别进行拆分，使页面首次打开时仅需下载必须的资源文件，然后根据路由的跳转或者用户行为预判，去懒加载和预加载对应的JS资源文件。对于CSS资源也是类似的处理方式，都是需要根据实际的业务场景和诉求微调拆分策略。对于依赖文件，根据二方包和三方包更新频率的不同，也进行了进一步的拆分，某种意义上也是前端视角的“动静分离”
- 对OSS全站JS、CSS资源设置了HTTP强缓存头，在构建时发现文件发生改变则会生成新的hash命名文件，客户端则会拉取新的资源文件，这就要求HTML文件需要设置为no-store的缓存策略，确保每次能够立马拉到最新的资源
- 对用户端的图片、音视频资源文件进行优化，无外乎是从格式、宽高、质量等维度，像webp这种压缩率更高的图片格式，在安卓端可以全量进行使用（我们的用户七成以上是安卓手机）。这里我们还参照了很多优秀电商产品，在不同场景下设置不同的标准规范，既做到资源的控制，又保证了用户侧的基本体验
- 用户端主动上传的资源文件，主要是在一些内容相关的业务场景下，对于这些点，我们也是参照了业界一些优秀的内容类业务应用例如美团、小红书，对用户上传操作进行了客户端压缩处理，在中后台系统一些前端不太适宜做压缩的场景下，采用了服务端压缩的方案。通过这些方式，既可以有效的控制了上行流量的大小，又间接的缩减了这些资源在前端呈现时的下行流量占用
部分优化效果展示
1、成本优化效果
总流量由日均 11Tb优化到 5Tb，平均每天减少 6Tb
用户人均产生流量（总流量/UV）：九月从36.51Mb优化到 12.44Mb，十月优化到11.21Mb
2、性能优化效果
首页：九月从58.93%优化到 69.63%，十月优化到81.61%
会场：九月从54.94%优化到 68.84%，十月优化到83.77%
商详：九月从68.54%优化到 79.11%，十月优化到89.15%
到十二月底，已经全部达到90%以上
2、功能体验优化
针对供应链中后台业务，主要解决了核心功能体验差的问题，针对商家侧几个重要功能进行了重点专项优化。
商家后台首页作为一个平台的门面以及系统整体的UI框架，过去样式风格上存在较大的问题，整个系统缺乏设计感，没有规范的设计标准，给人的“山寨感”很强。以此问题为契机，我们与设计团队合作后初步地产出了后台系统前端界面开发的视觉规范，对首页和整个商家系统的头部及侧边栏进行了改版，很大程度的改善了平台的“面子工程”。
商品上传功能是商家在平台卖货的一个核心业务流程，也是使用频率极高的一个功能，可是在我们今年优化之前，这里的单品上传成功率只有不到5成，用户会遇到各种商品表单字段填写不规范或者系统故障无兜底、错误提示不人性化的问题，最终导致商品无法创建成功。商品批量上传的功能也同样存在问题，大体积的商品资源包文件也常会因100个商品中有一个商品的一个字段错误而返回失败需要重走流程，或者因为网络不稳定、网速较慢的原因导致上传中断或失败，系统却不支持断点续传。在进行了一系列技术功能和体验交互上的优化之后，在12月底用户商品上传成功率已经达到了9成左右。
体验优化效果
1、商品单品上传成功率：从3.91%提升到88.77%
2、商品批量上传成功率：从50%提升到97.07%
3、命中断点续传平均节省时间 57.18s
3、其他事情
1. 业务轮岗
年初业务迭代节奏稍缓的时候，曾尝试安排一名前端同学前往一线运营团队进行轮岗，一是为了技术同学更加贴近和了解业务现状，二是想试图发现目前运营平台存在的技术优化点。轮岗的方式不是简单的坐在工位旁边观摩，而是实打实的作为一名内容运营人员去真实的工作。经过一周的一线实操体验，充分感受到了同一集团中业务合作团队的真实工作情况，站在技术视角，发现了很多可优化的点。
优化点主要以提效类为主：包括一部分内部小二平台的功能缺陷、系统Bug和使用体验问题，以及一些可借助技术自动化的手段，去完成某些机械重复的操作，提高运营人效。例如像素材内容微信笔记生成的这一操作，前端通过一周的研发，借助Auto.js自动化脚本工具，便大约节约了过去运营持续每天两个人的工作量。
这次轮岗也是开了技术人员业务轮岗的先河，沉淀出一套技术人员轮岗的参考规范以及一些考评的制度，作为后面其他同学做类似的事情时的一个参照。
2. 埋点规范
2021年主要解决了过去埋点需求管理乱、埋点数据维护难的问题，并且引入埋点区块、模块的概念，提供更加精细粒度的数据分析能力储备，三端（App、小程序、H5）进行了字段格式统一，满足各业务线通用，通过对埋点平台的完善，支持了在新的标准规范下维护全平台的业务埋点需求。集团业务交易主流程基本覆盖，关键流程例如搜索、分享等也已经覆盖，为后期清洗和数据分析做好了储备。
3. 监控体系
前端监控体系过去几年里事实上已经打造的比较完善了，基础的异常、性能监控已经具备，突发性的大数量异常也会触发告警提醒开发人员紧急处理。今年在监控方面做的主要是对各类指标的进一步的细化与完善，例如对异常监控，明确分离了资源加载错误、业务接口错误以及JS逻辑错误的统计，针对每种类型错误定制不同告警策略。
性能监控方面，核心的指标是前端秒开率，而对这个秒开率的计算方式，我们进行了新的调整。过去我们是以首次渲染完成时间（小程序的onReady生命周期）和前端资源加载完毕的耗时（H5的onLoad事件）进行计算，简单来说，就是页面被打开了，存在有效的内容被渲染。而用户侧真正的感官体验，应该是业务内容完全呈现，例如商品信息、会场信息、活动信息等等，即可交互时间（而非白屏时间或者首屏时间）。
基于此变化，我们重新补充了我们的指标规范并完善了相应的SDK及监控表盘，通过监控表盘，我们也能够明确的识别到我们接下来要解决的问题，制定进一步优化的规划。
4. 新技术能力落地
上线了小程序的长按微信聊天窗口素材进入图搜功能，搜索结果页在产品、设计同学的推动下，也做了交互上的统一上线后数据统计，通过长按图片进入的PV占到总图搜PV的40%，使用率不错。
4、团队的改变
2021年对自己的团队成员整体是比较满意的，几个关键的点是
1. 拥抱变化快速调整
2021年业务和团队上还是经历了几次比较大的调整，前端团队都能快速做出变化，组织架构上的灵活调整使得业务能够快速被支持和响应，这离不开几个前端业务TL的管理能力以及前端整体成员优秀的的基本职业素养
2. 技术中台赋能业务
前端团队经过几年的沉淀，内部对技术与业务的紧密结合已经达到了很高程度的默契，大家非常善于在业务中找到技术赋能的切入点，今年上半年几个中台化能力的落地就是最好的证明。下半年的成本优化、性能优化，也是前端同学冲在最前面，紧盯数据持续优化，拿到了非常不错的结果
团队中待提升的点
虽然这一年在现有技术架构之上有了更多深度的探索，但是在新技术领域缺乏太多涉猎，这可能会导致团队整体技术更新不及时，错过很多优质的问题解决方案。
因此，2022年会在一些新的技术领域持续发掘，发现更多的新技术在业务中的切入点和优化空间，例如之前调研过的UI设计稿转代码方案，能够继续进一步提效业务开发；Severless在海报生成node服务中的落地，优化机器成本问题；NoCode方案在中后台场景的落地，我们已经在正在做的工作流移动审批项目中开始尝试，配置化快速生成表格表单，提高业务响应效率。
三、2022年的规划和期待
1、性能体验（秒开率持续优化）
目前有关性能的问题，待优化的点已经比较明确，优化策略大体可以总结为
- 更早的调用首屏接口
- 接口返回更小的体积
- 静态的接口使用缓存
2、稳定性
1. 团队技术规范
下班年因为项目节奏整体比较紧张，倒排需求多，很多过去既定的规范权衡之后进行了部分舍弃，代码review、代码规范、项目发布等规范都有不同程度的松懈，虽然短期内效率有一定的提升，但是长远看对线上稳定性和项目的可维护性还是造成了一些伤害，带了一些隐患。2022年还是希望能够重新把规范抓起来，发掘更多的自动化工具，尽量在保证效率的同时，又能做好基础的研发稳定性保障。
2. 前端灰度发布
前端灰度发布是一直缺失的一项能力，不同于后端代码发布可以按机器分批发布，前端发布默认都是全量性的发布，这是一件存在较高风险的事情。目前小程序已经可以支持到按百分比、按地域、按用户白名单等多个维度的灰度发布，明年会在我们的小程序业务发布中强制推行，但是H5端和PC Web端的发布目前没有快速可行的落地方案，可能要基于Nginx和CDN做一些技术改造，需要年后与运维团队交流合作推动这件事情。
3. CDN监控
不同于前端代码异常监控，一般情况下可以收集到比较完整的错误堆栈，CND资源的异常报错，目前只能依赖腾讯云的CDN日志查询服务，里面对异常现场上报的信息十分有限，排查问题基本靠猜，导致问题修复极慢，线上用户问题得不到解决。所以年后需要立即推动这件事情的落地，无论是尝试前端技术侧的监控方案尝试，还是推动运维与腾讯云方提出日志服务优化需求。
3、业务增长（AARRR模型下的不断优化）
团队内的《增长黑客》读书会给我带来了很多看待业务和技术新的视角，认识到了前端技术在业务增长这件事情上，蕴藏着巨大的潜力和无穷的想象力。之后也在业务中做了一些简单尝试，借助微信公众平台的一些开放能力，在小程序中做了增长实验，得到了不错的正向反馈。明年的计划，主要是与产品、设计团队长期合作推动AARRR模型下对业务增长的不断实验和优化，借助科学的理论模型，发现我们的问题，小步快跑，持续发力。
4、对自我的一些改变和期待
1、调整过去的管理方式，更多的关注给一线的开发同学
2、对团队技术上有更多深度和体系化的输出
3、写更多的代码，了解更多的业务细节
