门神——转转前端代码校验系统

序

每逢新春佳节，家家户户都会按照习俗，在门上贴上凶神恶煞的门神，希望能驱邪避灾，保护家人平安。

而转转 FE 团队，也在农历新年前，正式上线了门神系统——一个在 编译 & 部署 环节可以通过静态扫描，发现并拦截含有不安全代码的项目上线的系统，保护线上项目稳定运行。

背景

我们先从几个简单的场景入手，来发现业务开发中的一些常见痛点。

首先，即使转转 FE 团队有着非常完善的脚手架支持和 git commit  规范，并搭配 githook  以确保每次提交的代码都是经由 eslint  校验通过的，但这里面也有两个显而易见的漏洞：

1. 本地 .eslintrc  文件中的规则可以随意修改

2. 可以通过 git commit -n  指令轻易绕过 githook  设置的钩子

而我们既不能保证开发人员在匆忙上线时还能保持高度自律，也无力在繁忙的的业务代码开发中推行全面的 code review，所以我们需要借助自动化工具，对其中比较危险的 eslint  错误进行拦截，比如使用了未声明的变量（ no-undef ），确保线上代码不会出现低级错误，这是其一。

其次，据前段时间运维反馈，前端项目访问了不少返回状态是 404  的链接。经排查，这些链接大都指向了错误或者失效的图片地址，比如旧的 58CDN 地址的图片，如果未经处理，无疑非常影响用户体验。所以我们要求所有图片链接都需要经过基础工具 setPicSize （转转内部对 CDN 图片进行解析、压缩等操作的工具）的处理，统一修正错误地址的同时，也能在访问出错时提供兜底方案。显然，这份枯燥而又不可省略的检查和修复工作也需要自动化工具的帮助。

最后，我们需要确保项目使用了必要的基础库，充分发挥转转 FE 团队的基建能力，比如：

1. 确保项目接入了 lego  性能上报系统，上传用户页面性能数据，为性能平台做统计提供真实的原始数据

2. 确保项目接入了 sentry  线上监控系统，及时发现并上报线上报错

3. 确保移动端项目使用了最新版本的 zz-ui  组件库，使用了统一的、最新的 UI 样式

上述三个方面，都是需要能够收拢管理，以保证项目质量的地方，但是在传统的开发流程中却很难实现。可能在线 IDE 方案可以解决这些问题，但是对现阶段的转转 FE 团队规模而言探索在线 IDE 方案无疑是不现实的。所以转转 FE 团队提出了门神系统的概念，作为项目上线前的最后一道防线。这其实也和业界很多优秀的前端团队的方案所见略同，比如阿里的飞冰团队开源的 iceworks，从 5 个维度给代码打分；京东 FE 团队也在几天前分享了他们基于 EOS-JS  引擎扫描代码的方案...

预期

这个功能的业务需求很直白，就是扫描并拦截有问题的代码上线。但如果我们希望设计一个高可用度、高拓展度、功能完备的代码校验系统，那要做的还有很多。

门神系统项目第一期的目标大概分为以下几点：

1. 无缝接入现有的代码部署系统，侵入性小，业务无感知