前言
前阵子 winter 应邀来我司做分享, 有幸混了个圆桌嘉宾参与交流, 其中 winter 谈到关于前端架构解决的问题域, 从他在淘宝的经历, 他理解当时他所做的前端架构主要解决的是大数量页面生成的问题, 当时感触不深, 在今天之前, 我对前端架构的理解一直是广义的, 即架构本身要解决的就是复杂性, 将复杂的东西简化, 以便更好的维护, 前端也脱离不开这个范畴, 但是今天因为要写转正 ppt , 在构思脑图的时候, 我突然意识到前端架构其实是有更明确地含义, 并且在这些年, 我们这些在不同领域从事前端架构工作的架构师都有自己的一些理解, 但此刻我突然发现了其中的共性, 这种发现让我忍不住上来撸篇文章和大家做个分享
正文
多年以前, 我从不理解架构师, 到从事前端架构, 到自己产生了一些理解, 期间也写了不少关于架构, 关于前端架构的文章, 但总感觉还是过于抽象, 包括我和团队的同学交流, 总觉得缺点什么, 这种抽象和实际的架构工作之间还少了一层, 直到听了 winter 的分享, 结合这些年的经验, 我突然意识到, 前端架构是有具体的抽象问题域的, 而不是简单的用降低前端技术的复杂性来解释, 在回答这个问题之前, 我想先说下客户端软件架构师 和 服务端架构师.
客户端软件架构师
考过软考的应该知道软考有个级别叫系统分析师, 或者有的也叫软件架构师, 软考对此的定义是能够主持参与系统分析, 软件架构等工作, winter 在分享的时候提到了客户端软件架构师, 在这里是相同的含义
winter 指出客户端软件架构师的架构工作主要是为了控制解决客户端软件设计上的复杂性, 一个客户端系统, 尤其是类似 OA, ERP 开发周期从 6 到 12个月甚至更长, 这样复杂的长期的软件工程, 需要有专门的技术人员负责统筹把控代码的质量, 而客户端软件架构师的工作就是围绕这个展开的
因此客户端软件架构师解决的主要是软件本身的复杂性.
服务端架构师
随着 BS 的发展, 互联网和大数据时代的来临, 现在某些系统 1天产生的数据可能是过去传统软件 1年产生的数据, 这种极大量数据的操作带来的问题变得日益严峻, 为此服务端架构师孕育而生, 服务端架构师始终围绕如何降低因为数据操作量增长带来的系统复杂性而努力
由此发展出来的高并发, 分布式, 微服务, 云原生等等都是服务端架构师们为此努力的结果, 包括一些关于数据库方面的学术性的成果, 例如最著名的 "CAP 定律"
重头戏 → 前端架构师
架构师围绕降低复杂性展开工作, 这一点我在之前的文章讲得其实很多了, 而在这里, winter 关于前端架构围绕提升淘宝页面的生产效率这件事的分享让我有了一个更清晰更直接的认知
前端架构师们自始至终都在围绕降低一件事的复杂性而努力.
那就是降低差异性需求增长带来的复杂性这件事
为什么这么说?
我们不妨回想下, 在过去很长的时间内, 前端一直试图通过可视化拖拽的方式来生成代码, 现在我们称其为 no-code, 但是这种么做的原因是什么? 我们为什么要试图去做这样一个系统, 从我的角度看, 可追溯的 no-code 系统最早可能就是那些建站工具类似于 XX CMS 这种, 由于服务端的数据操作天然和用户是隔离的, 服务端工程师不需要为了解决用户各种各样的需求而去修改数据操作的基本代码, 因此在没有互联网和大数据的年代, 软件工程师中并没有衍生出服务端架构师这样的角色.
基于这样的一种职业衍生路径, 前端架构师的最早诞生可能就来自于对前端代码的可视化开发需求, 就像 winter 说的, 当淘宝需要成千上百的运营页面开发的时候, 大量的重复性工作根本无法依靠人力来完成, 为此小部分优秀的前端工程师开始演变成前端架构师, 他们从最初的研发工作转变成为了降低这一问题的复杂性而努力思考的职业
但在这一时期, 前端架构师这个职业依然很模糊, 大家也不知道前端架构师是干什么的, 既没有系统性的理论知识, 也没有可复制的架构模式, 我们依然靠经验来推动一些前端架构工作, 但随着中后台系统的发展, 需求带来的复杂性, 从运营页面扩展到了内部系统, 为此在阿里诞生了飞冰等一系列以物料为基础构建中后台的系统, 我理解这是前端架构的第二次发展
经过两次发展的前端架构开始有了一些被沉淀下来的理论, 可复制的模式, 越来越多的可视化构建系统, 基于物料的前端搭建系统开始冒头, 但在这一时期, 前端架构依然是模糊的, 同时前端架构师开始进入大家的视野, 越来越多的团队开始招募前端架构师这样的角色
但事实上大部分前端团队招募前端架构师往往不是为了解决架构问题, 更多是为了解决团队管理问题, 你仔细看那些招聘你会发现其实招聘的只是个更懂技术的前端 Leader 而已.
并且在这一时期, 因为部分 SPA 的复杂性加上混合开发模式的发展, 加上 Nodejs 带来的全栈的概念, 进一步加重了前端架构领域的混乱, 我们越来越搞不清楚前端架构师到底要做什么, 这种混乱也给这个职业发展本身带来了极大的问题, 因为我们不知道要学习什么, 因为我们不知道自己到底要解决什么问题, 似乎前端所有的复杂性都需要架构师去解决.
也正是如此, 我才对前端架构师的理解倾向于广义的架构师理解, 即一切技术的复杂性都是前端架构师要考虑的问题. 但现在看来这其实也是一个误区.
让我们剥开迷雾, 抓住核心.
前端架构师的核心工作是降低需求增长带来的技术实现的复杂性
这句话可能有点绕口, 但展开来讲并不复杂
因为运营页面需求的增长, 我们打造运营页面搭建系统来降低技术实现的复杂性
因为我们要在不同端实现相同的需求的增长, 我们开发各种通过 DSL 实现一次编写多端生成的系统来降低实现需求的复杂性
因为内部系统重构的需求的增长, 我们基于 Next.js 这样方案去打造中后台搭建系统, 降低实现这一类需求的复杂性
像字节这种因为大量 App 生产的需求, 内部肯定搞了 App 工厂系统这样的东西来降低这一类需求实现的复杂性
就像服务端实现微服务分布式有不同的技术选型, 前端也一样, 打造相同的 no-code 系统你可以选不同的技术栈来实现
一个有经验的服务端架构师可以快速搭建一套分布式系统来降低数据操作量增长的复杂性.
那么一个有经验的前端架构师就应该可以快速搞出上述这一套套东西来降低这类需求实现的复杂性.
因此, 一家公司如果没有数据操作量上的增长, 比如流量, 大数据, 那他就不需要一个服务端架构师, 同理, 如果一家公司的前端需求增长依然是人力可控的范围, 那他也不需要一个前端架构师. 最多需要一个前端 Leader.
后话
过去我只发现了成为架构师的思维转变路径, 和抽象的一些方法, 但现在我明确的知道如何去培养一名前端架构师. 大量的差异化的需求就是一个前端架构师成长的基石. 过去我们之所以没有像服务端那样诞生大量的前端架构师, 原因是在消费互联网时代, 只有少数公司才会有大量的运营页面的需求, 才有钱去搞内部系统翻新这种事情, 搞中后台. 对前端架构师的需求远远少于对前端Leader 的需求, 为此很长一段时间, 前端专家这个角色在架构和管理之间游走, 非常容易迷失自己.
但是显然随着产业互联网的快速发展, 越来越多做企业服务的公司会需要前端架构师, 因为企业的需求是高度定制化, 差异化, 几乎不可能标准化的, 而前端架构师也不会需要一套拿来即用的类似飞冰这样的系统, 而是应该会像服务端架构师一样, 发展出更多框架和工具用来打造专属于自己业务的类似飞冰这样的系统, 就像可视化搭建在很多公司都如火如荼的打造着, 可以说未来不会出现所谓大一统的前端可视化搭建系统, 而是会出现各种新的框架用来打造这种系统, 类似 SpringCloud, 我相信这也是前端开源社区的又一次巨大进步.
