为前端工程之崛起而编程！
作者 | 蚂蚁保险体验技术团队
责编 | 胡巍巍
本文经授权转载知乎“相学长”
曾经在知乎的一个问答《从事前端真的没有后端工资高？》中谈到自己对前端工程师的天花板的认识：
我觉得，随着互联网产品越来越多，用户们必定也会不断的索取更好的用户体验，前端同学也会扮演着越来越重要的角色。责任越来越重，天花板就越来越高(诶，自己说的话，貌似也没必要加什么引用......)。
当时的角度主要注重产品体验上。现在入职蚂蚁1年左右，对其又产生了一些新的想法。虽然前端的能力越来越强，技术栈要求也越来越高。但从工程角度出发，前端目前还处在一个较低的阶级水平。
首先，我们作为前端工程师，是怎么定义这个“工程”的呢？
何谓前端工程
我刚毕业的时候，在一家创业公司做全栈，职称是Web开发工程师。当时前后端未分离，而我内心的工程，就是我手头整个前后端工程代码。当时对前端工程是没有概念的，对我而言，前端就是JS+CSS+HTML，它脱离了服务器就没了意义。单把这些代码拎出来，我也无法称之为工程。
后来三大框架出现，前后端逐渐分离，开始出现“前端工程化”的概念。2017年初时，曾面试过一家小创业公司，面试官问我前端工程化怎么做？
当时我回答：“前端工程化就是：代码模块化、功能组件化，打包、构建、发布自动化、流程化。”在后面的一年中，我的工程化概念，大致还是如此，可能还会加上一个开发规范。
在这个“工程化”概念下，我所认为的“前端工程”，就是我眼前的 “前端代码”，它的最终目的是为用户输出前端页面。
我最关注的即是：如何更高效率、更高质量的为用户输出体验更好、能力更多的页面。这些年前端Coder围绕着这点也做了很多：
高效率：
- ES6+
- 多端统一
- 接口管理与Mocker
- 框架、工具库、组件库
高质量：
- 开发高质量
- Git
- Code Review
- 开发规范
- 线上质量保证
- 监控系统
- 应急-快速回滚能力
更好的体验：
- 多尺寸适配
- 小程序
- 高性能
能力更多：
- 复杂交互
- Native能力
- 动画、游戏
当然这其中也有一些交集，比如三大框架的出现既为高交互页面提供了可能性，也提高了整体开发效率与质量。比如围绕高效率与高质量会统一建设一个前端迭代管理系统，负责工程迭代、构建、发布、回滚。
其实我也就随便列列，有很多东西都没涉及，但也能感受到这几年前端领域的突飞猛进。再站在现在这个时期，看前后端未分离的时期，那段后端兼职JS、视觉兼职CSS的上古年代，确实不能称前端代码为“工程”，更不太好意思说前端程序员为“工程师”。这也难怪很多高校老师、后端同学不屑前端。
但立足现在，前端所涉及的范围已经远远超出了当年，我们的“工程”复杂度与其能拥有的能力也超出当年的想象。我们可以骄傲地说自己是一名前端工程师了。但我觉得，我们似乎离软件工程师还差一点点。
前端工程师，首先是软件工程师
网上有很多人，都说过这句话。说的似乎很有道理，却又没啥体感。而近几天我对这句话感受日深，这其中很大原因归功于蚂蚁在Node上的丰富实践。
蚂蚁应该是实践Node比较多的公司了。目前蚂蚁的大部分移动端业务，都有对应的体验适配层BFF层，也即大家通俗理解中的Node中间层。
它的主要职责为：衔接页面与后端，聚合后端接口，做好数据转化，输出最满足页面期望的数据结果。
它的主要目的为：让后端更专注于领域模型，将页面数据的设计交与前端，彼此更专业高效。更通俗点说：让业务开发更快！
而加入蚂蚁后，BFF层可以说给我增加了很多工作量。我们需要开始给自己页面设计接口，需要对接多个后台系统。新增接口，可能需要考虑拓展性；旧的接口变更，需要考虑兼容性。
如果涉及后端变更，需要评估其变更影响，需要评估系统的依赖与发布的先后顺序。此外还需要考虑需求上线时，Node层与前端的灰度方案、监控方案、应急方案。
所以在我们组，业务需求所涉及的前端变更是需要做系统分析的，后端系统分析也是要参加的，这些涉及了上述所说种种。
尤其是当需求变更较大、波及较广，甚至还同时涉及了多个系统间的迁移、升级、重构，这其中的复杂度便会迅速上升。对于体量较大、用户量较多的业务，这就是对工程师的一个考验了。
当你不断的经历这些挑战，可能突然有一刻，会有种感觉：作为一名工程师，以前都只关注自己手头的前端代码，对于整个软件系统工程的思考实在太少了。
在这个软件系统中，前端所涉及的工程扮演着哪些角色？哪些系统影响着它？它影响着哪些系统？它们的变更都会产生什么影响？
所以前端工程师，其作为一名软件工程师，应该从整个软件系统工程去看。前端工程师不仅仅是完成自己的前端工程，而是完成了整个软件系统中的一部分，它也不会脱离整个系统而独立。
而作为整个系统工程的一部分，前端工程要懂得去索取，懂得去影响，了解整体工程的能力与痛点，思考整体工程如何去提高。
这时候再来看这句话：前端工程师，先是软件工程师。不知道大家能否多了一些体感。
前端地位低
但如果我们从整个软件工程来看，这时候我们就会意识到一个惨痛的事实：前端工程在整个系统工程中的地位太低了。
在蚂蚁，前端工程师往后走了一步，多了一层Node层，在整体系统工程中扩大了自身占比，还算好一些。
而对于大多数只涉及Web页面工程的同学来说，望着这个巨大的软件系统工程，即使有心，似乎也无力。
其实我觉得很多前端工程师是很厉害的。尤其是这几年，越来越多的优秀毕业生加入了前端。
有时候我会觉得，前端的交互逻辑如此复杂，其对代码水平的要求比后端大部分的业务场景高到不知道哪里去了。
但纯粹的代码水平并无法决定前端工程的影响力。即使你能用0和1敲打出一个天花乱坠的页面，那它也就是一个页面。
前端工程在一个软件系统中是处于最上游的（用户入口）。因此，也就没有其他系统需要调取前端系统的服务。
在整个软件系统中，前端对接的系统少，所影响的系统也少，工程地位低。不像后端，它既需要为前端提供能力，又需要问中后台、数据层索取能力，也可能需要问其他业务后端索取能力，对接系统很多，工程地位自然也高。
由此又会导致，前端往往不是产品能否实现的决定性因素。在软件系统中，需要上游系统调取下游系统服务。
换言之，上游依托于下游。这自然而然的导致技术评估从下游开始。到前端评估时，已经是最后一道坎了。
而这一道坎，业务方往往是无论如何也得过的。如果坎比较高（交互视觉难以实现），最终也是通过降低交互复杂度与用户体验，来保证产品功能先上。
有很多同学认为前端对业务的参与度太低了。但我们自我感觉对业务参与度也挺高呀，我知道产品都有哪些页面，都有哪些功能。
但了解并不是参与，影响才是参与。前端的工程影响力以及业务影响力，导致了前端对业务的参与度本质上是很低的。
在这种情况下，说白了，很多前端只是流水线工人。视觉稿来了，实现它。
实在实现不了，打回换一份更简单的视觉稿。可不甘心做一个流水线工人啊，似乎都能看到年纪大了以后被裁员的结局。那这又该怎么办呢？
前端的焦虑
前端仿佛一直处在焦虑当中。前两年我们的主要矛盾是日益爆发的前端新技术同前端程序员学不动之间的矛盾。
而这一两年前端技术栈趋于稳定，轮子相对也少了。加上前端程序员也比较拼，学不动的感觉也随着无数个夜晚的学习而渐渐逝去。
这时候前端又开始了新的焦虑，前端的天花板是不是太低？工资是不是没后端高？前端开发的壁垒在哪里？
我认为我们的主要矛盾已经发生了变化，变成了前端日益增长的工程地位诉求同前端工程局限性之间的矛盾。
聪明或勤奋，再加上时间的积累，总是能解决“学不动”的问题的。但前端工程地位诉求怕是自身再怎么努力也不一定能解决的。
解决当下前端焦虑的办法只能是打破前端工程局限，增加前端工程影响力，拔高其工程地位。最终让前端人员也能在软件系统工程中当家做主，平等的参与到软件系统建设当中。
只有前端崛起，前端工程师才能摆脱焦虑，而这不是一两个人的战斗，需要大家一起去努力实现。我个人想了三条计策。
崛起三计
1.无中生有
能从现有工程中发现痛点，创造出一个系统或服务，提高效能、促进业务出成果。
典型的如Node层，利用Node服务端能力，搭建一层为前端服务的BFF层。于是便在一个软件系统工程中，硬生生造出一层系统，拓展了前端工程师的工程地盘。
2.远交近攻
在一个系统工程中，我们多做了一部分工作，自然就有人少做了一部分。现在我们无中生有的，是人家不愿意做的“脏活累活”。
如果我需要侵占下游的核心能力时，他们便不一定让步了。这时候我们可以采取“远交近攻”。如果我们能直接对接下游的下游，同时又能拥有下游的能力。
那我们下游还有什么存在的意义呢？现在流行的FaaS似乎就给我们提供了一个Idea、亦或者就是个契机。
3.反客为主
前端虽然是上游系统，但可以通过提高自身工程能力，主动地放大业务可能性。将可能性的瓶颈下抛，进而促进下游系统提高自身能力。
化被动为主动，改接受为影响，进而提高自身工程地位。典型的如小程序。小程序最初是由客户端同学去实现，最开始其实也是致力于平台生态问题。
因其技术栈基本与前端契合，极大了利好了前端开发者（而不是客户端开发）。前端开发同学疯狂涌入后，一方面做了非常多基建工作，极大提高了小程序开发效率。
另一方面，大量的小程序让业务看到小程序的无限可能。进而对小程序本身能力也多了很多诉求，如微信小程序支持了NPM包。社区里，前端程序员在小程序建设上不断努力，如今说到小程序，大家似乎都在夸前端厉害。
相信随着无数优秀的前端同学不断的奋斗，几年以后的前端工程师必然又是另外一番成就。
希望届时，我们可以骄傲的称自己为一名软件工程师。我们依旧会不断学习，但学习的背后不再是因为焦虑，而是纯粹对于工程与代码的热爱~
加油吧前端程序员们！让我们一起为前端工程之崛起而编程。