论前端技术和前端工程之辩

前言

在面试的时候, 我们经常会谈论到面试需要考察一个人的技术深度和广度, 但实际操作中, 经常会遇到情况是, 面试造火箭, 进来拧螺丝.

我曾看到知乎中一些做算法的同行曾经讨论过, 关于算法和算法工程之前的区别, 对于算法研究并不是算法工程师的工作, 对于算法工程师而言, 更多的是参数调优, 当然能做这件事的前提是你得懂算法. 但干我们这一行的都清楚, 虽然做工程做业务是就业路子最广的, 但是时间长了在技术上的深度和广度都会受到影响.

而对于软件工程师, 或者前端工程师而言, 如果做工程, 做业务没有出路, 业务经验再丰富连基本的面试都通不过, 积累工作经验的意义又何在?

如果你做过管理, 我相信你一定曾经有过这样的心态, 招人用人喜欢年轻有想法有活力的, 但是在面对业务压力的时候依然会选择让那些业务熟悉的老人来顶, 虽然内心觉得此类往往缺乏潜力, 但真正能扛得住事的却恰恰又是他们.

业务经验毫无价值, 在面试的时候往往一笔带过, 但是实际工作中承担业务团队重心的却恰恰又是业务经验最丰富的的人. 为什么会有这种矛盾? 这个问题一直困扰着我. 直到最近才有些心得, 决定拿出来跟大家分享.

正文

什么是前端技术?

如果有前端开发技术, 前端研发技术与应用这样的学科, 你觉得会包含哪些内容? 参考在大学中学过的计算机科学与技术, 我相信对于前端技术而言, 主要包含的应该是这些

• Html Css JavaScript 基础
• Web App 开发技术

所以从这个角度看, 你会发现你日常工作中 90% 以上的内容和前端技术毫不相关, 回想下自己今天的工作内容吧.

• 开需求评审会
• 开设计评审会
• 开某个技术方案讨论会
• 跨项目启动沟通会
• 做下来写了两行 css
• 写了一个 function
• 打包到测试环境调试了下
• 改了两个 div

毫无意义?, 既然日常工作和前端技术毫无关系, 自然无法提升任何技术深度和广度, 只能在面试的时候获得一个 业务经验丰富, 做业务没问题的评价.

那究竟啥叫前端技术, 或者说什么叫做搞前端技术的?

答案其实就在上面, 只要把 2 个大类拆解一下

• Html Css JavaScript 基础
  • Html 语义化, w3c 标准的研究
  • Css 标准的研究
  • JavaScript 语言的研究, 参与和贡献新的语法提案

这三块和大部分人都没啥关系, 这种基础技术的研究工作通常都不会落在普通人身上.

• Web App 开发技术 这个就海了去了
  • 数据可视化技术的研究(d3..)
  • 浏览器 Api 操作代码封装技术的研究(从操作 dom 到操作各种 webapi 都属于这一范畴)
    • dom 操作(React vue ...)
      • 特定技术栈下的代码封装技术的研究(redux, vuex...)
    • webapi (流媒体, 动画 ...)
    • 浏览器兼容性处理(borwserlist, autoPrefix...)
    • ...
  • JavaScript 代码封装技术的研究(lodash 就属于此类)
  • JavaScript 编译和执行技术的研究(TypeScript babel v8 等)
    • 特定技术栈下的代码封装技术的研究(babel-plugin ...)
  • css 编译和执行的研究(scss, less, postcss...)
    • 特定技术栈下的代码封装技术的研究(postcss-puglin...)
  • 代码生成技术的研究
    • 快速搭建
    • DSL
    • 图形化编程
    • 动态配置系统
  • 自动化技术的研究

    • 持续集成

    • 打包构建

    • 发布部署

    • 数据分析与监控

    • 特定技术栈下的代码封装技术的研究(webpack plugin, loder...)

各位可能会有点好奇, 似乎少了什么, 比如 nodejs, rn flutter 等? 如果看过我之前写多文章, 应该了解我的观点, 上述均不属于严格意义上的前端技术范畴, 包括 nodejs

nodejs 作者开发 nodejs 的初衷也不是为了前端技术的发展, nodejs 在自动化技术上的应用, 对于前端代码模块化封装技术的推动是一个副作用.

如果你不做任何和服务端相关的事情, nodejs 对你而言几乎是透明的, 只是为了用来执行

npm i hello-world

来来让我们对照下, 上述内容是否和你的日常工作有关系, 别沮丧, 虽然我知道 80% 的人会回答 No!

没错大部分前端的日常工作和前端技术毫不相关, 你唯一需要做的仅仅是用你所了解和掌握的前端技术去解决问题, 不是这些技术的问题, 而是业务需求.

当我们讨论一个人的技术深度的时候, 我们其实就是在谈论在上述技术领域的任一分支下, 你是否拥有足够多的实践, 足够深入和透彻的了解.

如果深入和透彻了解还能面前靠阅读源码和文章, 通过思考和悟性解决.

但足够多的实践却能卡掉大部分人提升技术能力的机会. 想想什么样的部门或者团队有机会去实践?

反正不是业务团队就对了!!!

在业务团队你最大的可能性大概就是研究下特定技术栈下的代码封装技术, 例如 webpack plugin, babel plugin 等, 但是大概率也是非常浅显的

那么搞业务, 写业务代码是不是就是没有出路的工具人, 资源符号? 绩效淘汰备选对象?

说句实话, 从我这么多年的经验和身边的例子看, 90% 的前端写业务, 90% 里的 80% 都面临被持续淘汰的风险, 一般都是过了工作 5 年这个节点, 开始不断的被淘汰, 从大厂到中厂到小厂到外包, 无论你是做管理还是做技术, 随着工作环境的恶化几乎难逃越混越惨的命运.

但如果这是我思考的结果, 那我就不写这篇文章了, 因为接下来我要谈论不是广泛所指的前端工程, 前端工程化等概念, 再我看来, 当下谈论的前端工程化依然只是上述技术的一根分支, 属于自动化技术的范畴, 说是搞工程其实就是搞技术, 我要讲的工程是实实在在的工程, 紧贴业务的工程.

因为我也是常年业务团队出身, 我一直在思索破局之法, 我相信占据了 90% 前端工程师精力的事情不可能是这种毫无意义注定走下坡路的工作, 这里一定有啥是不对的. 或者不科学的.

为此让我们进入本文最重要的部分

什么是前端工程

什么是搞前端工程?

在大学里有一个专业叫软件工程, 在研究生领域也有专门的软件工程硕士, 当年我看过的软考教材里也有一个职称叫软件工程师, 从位阶分类上, 软件工程师在程序员之上. 在系统分析师之下.

回顾下软件工程领域的经典之作吧

在上面章节中提到的所有技术分支中, 或者你回想下在你用过的 JavaScript 库中是否有一个库是给你快速应用设计模式的?

我想应该没有, 因为设计模式最早是用 Java 写的, 随后的几年有人用 JavaScript 翻译了这些模式, 但代码已经老旧了, 或者说部分设计模式已经被 JavaScript 语言的天然特性所解决了.

包括在 Java 内部也一直围绕 设计模式 是否还持续可用持续着不断的讨论. 所以设计模式是一种技术么? 或者说设计模式能变成一种直接可以使用的技术么, 比如 React ? Vue ?

显然不行, 因为设计模式只是一种抽象方法, 是使用面向对象语言在进行软件研发, 组织软件工程所使用的的快速思维模板.

这种模板可用于任何满足模板使用条件的语言, 例如 OC Java JavaScript 等

因此对于前端领域的工程, 或者说有别于前端技术的前端工程这件事, 究竟是在搞啥. 我给的定义是

前端工程是指采用前端技术组织前端代码开发和维护前端项目

所以搞前端工程,做业务的人的出路在哪? 或者说除了谋求一个管理岗位, 有什么是广义上的前端编程技术可以让我们实践和研究, 我们自称为前端工程师, 但是干了这么多年真的有在前端工程上花费过多少心思呢?

广义上的前端编程技术包含了前端技术和前端工程

我这么说完, 估计会被人喷, 说的容易, 具体怎么搞? 难不成大家都去当四人帮?

怎么搞? 很难搞, 事实上前端工程的研究难度远大于前端技术. 为什么?

因为前端技术是标准的, 就拿难啃的 EcmaScrip 规范举例, 在难啃, 只要你头够铁, 也能啃下来. 或者以 V8 引擎举例, 不好啃, 怕啥 chrome 源码都啃了还在乎加一个 V8 么?

React Fiber 好啃么, 也不好啃. 但是这些东西都是技术标准, 在一段时间内是确定性的, 你只要有足够的时间, 你都能啃下来.

但是业务是高度不确定的, 围绕业务建立起来的前端工程同样是高度不稳定的, 所以如果要在业务端, 在前端工程里要搞出高度来, 还真的很难.

如果说搞前端技术, 最终的路径是往前端基础架构方向深入, 那搞前端工程, 搞业务, 就应该同样有一条路径通往前端业务架构.

说到这里又不得不提下前端编程技术架构的两个分支了

崭露头角的前端基础架构和完全摸不着头脑的前端业务架构

在一些大厂, 近几年已经开始流行在前端团队中搭建特殊的部门, 前端基础架构. 其实这并不是新鲜事, 在我看来这是前端技术发展趋于成熟的一个标志, 对既往的前端技术进行更有效的统一资源投入研究, 通过组织力量来匹配.

但另一个架构分支, 前端业务架构, 你可能听过, 但目前在各个团队的组织架构中基本不存在这样的人或者这样的岗位, 如果有的话欢迎交流, 因为我就是

前端业务架构师

目前我们团队对前端业务架构师的定义是, 成为前端业务和前端基础架构的纽带, 同时致力于打造前端业务中台, 有效避免业务组织架构的调整对前端工程的影响

怎么理解? 如果你从事或者想从事这个工作欢迎和我交流, 本文暂不深入.

还是让我们回到广泛的前端业务工程上来吧.

组件提取和 CV 大法其实都是死路一条

前端社区近 10 年的发展可以说是典型的残疾模式, 一条腿特别粗 → 前端技术, 另一条腿高度营养不良 → 前端工程.

基本上所有业务上的问题我们都是用技术思维去解决的, 但技术毕竟有瓶颈不是万能的, 技术解决不了怎么办? 两个办法

• 提取各种特定技术栈下的前端组件
  • jQuery 年代的插件
  • React 15 下的 hoc
  • React 16 下的 hook
  • ...
• CV 大法

组件听起来是一种抽象封装技术, 但在前端领域其实严格来讲应该叫标准件, 即忽视了产品和设计以及体验上的诉求, 根据特定技术栈的要求对代码进行封装后的产物. 为了解决业务开发上复用代码的需求. 甚至有一段时间, 前端团队为了让标准件稳定, 把产品和设计一块绑架了, 让他们闭嘴.

我们解决不了产品和设计提出的差异性需求, 所以把提出问题的人给解决了

只要产品不改, 设计不想, 一切完美.

但理想很丰满, 现实很骨感, 一堆公司花精力投资源搞了一堆的组件库, 最后还不如直接用 antd, 那些被提取出来的组件最后都陷入一种怪圈

组件就这个标准, 你们有需求要么你你们来改, 要不就用!!

参数已经不能再加了, 都 20 几个参数了...

不行啊, 这个逻辑其他团队再用, 给你们改了, 他们要回归, 要不我发个特殊版本?

需求越多死得越快, 前端目前所谓的组件就是这么个玩意.

你有这种经历么, 看到一个同事 CV 大法了一下然后义正言辞的跟他说, 你这么搞不行, 要提取组件.

在我看来其实 CV 虽然也是一条死路, 死得还比组件快, 但是 CV 也有组件没有的优点, 就是对代码修改的隔离.

目前很多社区方案提到的区块其实就是 CV 的一个改进, 不过虽然比 CV 好点, 能够统一集中管理, 定期升级, 但是依然无法解决改动后的版本的同步问题. 只能说一定程度上延长了采用 CV 大法的寿命

所以前端工程有设计模式么? 其实有的, 不过就 2 种

• 提取各种各样古怪的不统一的组件
• CV大法体系

这两种模式就是我们前端的基本编码抽象思维的快速模板, 也就是前端的设计模式.

他们各自拥有对方没有的优点, 但同时又有对方没有的缺点, 就像个太极图, 不过结果都一样, 都是奔着重写去的.

• 提取组件易于同步, 但是对差异化处理会带来参数膨胀, api 滥用的问题, 最后也是个死
• CV 大法可以有效隔离差异, 但是随着时间推移, 越来越多的版本同步问题也会摧毁你. 也是个死

所以前端工程是不是比前端技术更难? 对于一个致力于研究前端工程技术的人而言, 应该思考新的设计模式, 新的抽象方法来解决上述问题, 这才是 90% 前端的出路.

虽然是一条比搞前端技术更难的路, 但是却能给后来人踩出希望

关于这点, 我们团队在这方面有了些成果, 在 CV 和组件提取之外找了一条新路, 至于通不通, 等我分享了你们再品一品吧. 在我前面的文章中有提到过

Membrane Mode

在我们开发的 React 状态管理框架中也有部分展示, 可以移驾去看下, 如果你感兴趣可以顺手点个 star 😁

地址奉上: structured-react-hook

后话

继续招人, 招人一起搞事情, 搞大事情呀...如果你对前端基础架构和前端业务架构感兴趣, 请务必联系我, 我们需要你这样的人才 😁