共计 1561 个字符，预计需要花费 4 分钟才能阅读完成。
前言
来 B 站两年，简单记录一下这期间部门前端的变化以及自己的收获。
技术上的变化
17 年 9 月，我刚加入 B 站直播这个大家庭。当时前端主要业务重心在 web。
当时，简单的前后端分离已经完成。前端提供一个 html 模板放到静态资源机上面，html 模板里面引用了所需的 js 和 css，访问页面地址时，把这个静态模板返回给用户，然后执行 js，再通过 ajax 请求 api 拿到数据，渲染页面。
私有 npm 平台已经运行了一段时间，web 端的各种抽象组件在实际项目中已投产应用。
rider 发布系统已经接入，docker 打包之后发布自动到指定环境。
整体来看，前端技术上没有明显的短板，前端组件化、工程化实现程度较高。
步入 18 年，前端团队在技术上主要做了这几项：
重要前端页面 ssr + A/B TEST 分组实验能力
重点建设 Hybrid 能力
游戏引擎能力建设
整治代码质量
实现了对首页以及房间页的服务端渲染，并对这两项主要前端业务进行持续优化，大幅降低首帧时间 45%。对于重要的房间页，完成了基于分支发布的 A /B TEST 能力建设，可以支持多种分组方式，支持任意实验比例，可在线设置调节。
由于产品重心由 web 端转向移动端，Hybrid 能力开始建设，H5 页面与 App 的交互逐步增加，创建了半屏 webview 协议，使 H5 页面在 App 内拥有极大的灵活性。
但只有 Hybrid 是不够的，前端页面的首屏加载慢这一问题开始逐渐突出，针对该问题，接入了 app 的离线缓存，使重要的前端页面首屏与原生体验相近。
利用游戏引擎重构了扭蛋机项目，满足了设计对于该页面“恐怖”的动画效果要求。（感兴趣的可以点开 bilibili app -> 直播中心 -> 扭蛋）
针对代码质量问题，开始综合整治。利用内部工具，自动进行 TS Lint & ES Lint 检测；增加组件的 Unit Test。最终，代码的千行 bug 率小于 4，组件的单元测试覆盖率超过 50%。
19 年来临，技术总监对整个团队提出了使命：
Tech Redefine Living
这个很虚，但是自从总监分享过一遍他的规划之后，好好想想，我们可以一试（团队招人中，来了一起喝总监的鸡汤）！
个人收获
业务上提出来最好是解决方案，其次是问题
经常会遇到这样的场景，需求评审的时候产品运营当场表态，这个项目要求啥啥啥上线，啥啥啥功能要具备。压根不会管你手上有多少活，你现在有多忙，就是压缩开发时间，要求又快又好。
以前的做法：
做不完，找领导
自己加加班应该可以，闷头把事情做完，然后，交付给测试的质量并不合格，增大测试的工作量。
这种做法直接的结果是，自己心里充满了抱怨，感觉自己被亏欠了很多。
现在，我会提出具体的解决方案，比如，这个项目一定要做的话，它会影响哪些项目，这个项目的上线时间如果是定死的，那么哪些功能是必要的，必须完成的，哪些功能是“锦上添花”，可以二期或者直接砍掉的。
但是，如果真的事情已经超出自己能力范围怎么办？抛出问题，向上反馈，请求 leader 帮忙解决。
离开业务，技术很容易变成自嗨
之前的我，一直认为，能写出框架的才是牛逼的，能用上最新的技术才是牛逼的，能搞定所有技术问题才是牛逼的。
在 B 站的这段时间，改变了我的一些想法。脱离了业务的技术，很容易被忽略，因为并不知道这种技术可以在哪些地方应用，可以提升哪些数据。
不对业务起增益作用的技术，很容易成为一个人的自嗨，团队其他成员无法参与进来。
当技术能够与业务很好的结合的时候，自己的期望与团队的期望正好可以相互增益。比如，你想用 ssr 在线上项目，需要有严格的技术论证，确保自己可以 cover 住，降级策略是否存在等等。当把这些事情弄清之后，你就是团队里最适合做这件事的人，自己也能收获满足感。
总结
这两年，技术团队一直在变，一直在往好的地方转变。在今年，业务上的挑战很多，自我期望也很高，期望年底能够对这篇文章的内容做些增加。
