在阿里,我们不得不承认一个事实:前端的确有价值,但放在全局来看,前端产生的价值并非核心价值。 在阿里,虽然前端的工作已 经不可或缺,但对大公司而言,不可或缺的岗位多了去呢,不可或缺不代表有核心价值,我就不说了。

- 玉伯 2013 年 阿里前端的困局与突围

ceilling

image from Abbey Arches Architecture - Free photo on Pixabay

和 G 总论道

前几天和某大厂前端负责人 G 聊职业生涯发展,聊着聊着就谈到了前端和后端职业天花板。 我表达了自己观点:后端职业天花板更高,这是由职能细分决定。

后端(服务端)概念比较宽泛,常见分类可以有应用开发工程师、中间件工程师、甚至可以包含运维、数据工程师、算法工程师。 这里我只将后端工程师限定在应用开发工程师以及衍生的框架、库开发工程师。 前端这边由于引入大前端概念,概念也比较广,包含:Web 前端、移动端(iOS + Android 客户端)、桌面端(PC 端)。 这里我们也限定在这几个方向的应用开发。

有些同学可能不服气,现在基于 Node.js 也能写后端应用,并且已经有越来越多成熟产品。 单页应用推动了 React / React Native / Vue 等技术发展,这类前端框架也需要基于 MVC / MVVM 设计模式管理复杂数据流。 在端场景,Hybrid 应用愈发成熟,并且在一些特定领域比如 AI,iOS 也引入 Core ML 技术。 这样天花板还不够高么?

是的,尽管前端近年发展迅猛,探索出多种新技术,从更广泛端技术来看,Android / iOS 也迎来爆炸式发展, 几乎隐隐有势头盖过后端趋势。 随着业务复杂度提升, Web Frontend / Android / iOS 开发困难度愈发提升;随着科技普惠云计算发展, 技术门槛会进一步降低,当前前端工程师会有更宽阔空间。 但是仍然认为后端是更难掌握,职业天花板更高。

听我一一道来。

技术复杂度

为了避免争执,我们先来看看如何评估一项技术复杂度,这里拎出三个衡量技术复杂度维度:

  • 业务复杂度(业务结构复杂度、业务类型复杂度、逻辑复杂度、流程复杂度、颗粒度 x 关联业务复杂度、外部系统合作复杂度)
    • 量化指标:模型数量、模型属性数量、业务流程长度、业务条件分支数量、外部合作系统数量
  • 数据量复杂度(流量级别、业务数据量级、数据增长速度)
    • 量化指标:模型实例数量、服务用户数量 x 用户使用频率、增长率
  • 服务时效性(对外提供服务 SLA)
    • 量化指标:状态数量、面向个体服务时间、面向群体服务时间、在线要求可用率

由于服务时效性是一个动态概念,这里先基于业务复杂度和数据量复杂度画个简图:

    ^
  D |    +-------------+     +-------------+
  a |    |             |     |             |
  t |    |    Big      |     |  Complex    |
  a |    |             |     |             |
    |    +-------------+     +-------------+
  s |                                 
  i |                                 
  z |    +-------------+     +-------------+
  e |    |             |     |             |
    |    |    Simple   |     | Diversified |
    |    |             |     |             |
    |    +-------------+     +-------------+
    |
    +----------------------------------------> 
                                    Business Logic
  • 前端位于左下(可能会涉及到 Diversified(多样性),但即便如此,客户端 Client 无数据持久化,复杂度有限)
  • 后端位于右上(基础设施工程师支持 Big,应用开发工程师支撑 Deversified(多样性))
  • 数据处于右上(基础设施工程师支持 Big,数据开发工程师支撑 Deversified(多样性))

后端难

为什么后端更难挑战更大,有以下原因:

贴近业务。后端是业务逻辑忠实实现方和执行者,所有业务链路、业务分支、主流程和旁路都需要在后端有实现。 由于现在用户体验方面要求逐步提高,确实有不少业务链路和检查动作在前端呈现出来。 但这种链路即便有呈现,后端还是要进行建模、检查校验。 反观前端阿喀琉斯之踵,运行在端(浏览器 / 手机端),对用户透明,会面临安全问题。 从而导致数据无法持久化(即便持久化也是为了性能,这些数据不可信)。

可用性要求高。可用性体现在两个方面,实时可用性(也就是我们常说的 SLA)与面向未来设计(或者说向前兼容)。 前者要求系统是可以持续提供服务,这就带来了高可用、可扩容要求。这对整体系统设计带来了巨大挑战。 单点算力可用性增强的模式已经被证明不可行,分布式是被证明的可行道路。 后者对设计者提出了更高要求,系统需要兼容过去,还要给未来变化留下口子,当变化来临时候才可以低成本实现。 反观端上技术,本地无状态,无持久化数据,因此既没有实时可用性要求,也没有面向未来设计要求。

抽象程度高。抽象是为了解决业务复杂性和易变性,将具体业务以合理可扩展方式设计好。 这也是贴近业务的直接体现。 为了解决复杂业务下面抽象程度高问题,工程界提出了许多方法论。 设计层面有 DDD 领域驱动设计、微服务设计等;工程实施层面有各种设计模式、SOLID 开发模式、重构方法论等。 端上技术更多着眼在 UI 层面方法论:Reactive、Flux 数据流、动态热更新等。

上下游空间大。后端处于研发链路中间,前承端,后启运维数据算法,横接运营产品项管。 从我周围样本观察,当项目缺乏负责人时候,往往会从后端开发工程师挑选资深一员作为项目 Owner。 从人数上来看,后端往往也占据开发大的大多数。 由于上下游空间大,后端工程师职业天花板也会更开阔。转 DevOps / SRE / 算法 / 数据的后端开发工程师比比皆是。 这种转换非常自然,也提高了后端工程师的天花板。

贴近运行系统。当后端工程师部署他的项目,推动上线后,他往往需要对这个应用的运行环境有更多了解。 对于后端应用来说,生命周期可能是开发一两周,运行一两年。这种模式下面倒逼后端对 Linux 服务器环境有更多了解。 否则在生产环境运行时候,缺乏相关技能和工具掌握遇到问题就会束手无策。需要了解的还不仅仅是 Linux 部署环境, 还有相关的基础设施: RPC 系统、Queuing 队列系统、缓存系统、容器化环境等等基础设施。

给前端的建议

我看到有不少前端工程师们已经开始尝试突破天花板,进行「升维攻击」。我将其总结为这么三条:

  • 向后走:从直接实现业务升级往后端方向推进,从加速整体研发效率
  • 服务上下游:形成前端中台,比如无痕数据打点系统,飞冰、AntDesign(包括集团内部 BigFish / Basement)
  • 服务前端:从服务业务变为服务其他前端工程师,提供前端框架、Hybrid 框架、工具链、CICD 系统服务

PS:前端还有一类发力方向 - 复杂 UI 产品,比如 Web Editor,Google Doc、Office Online, 但是这类应用数量较少,开发技能点和常见应用开发差异较大,有志之士可以去挑战。

我给前端同学的建议:

  • 不要被手头事情限制住,也不要被 Title 限制住,开阔自己的技术视野,和上下游多合作,去理解上游业务和下游技术点。 这个建议对后端工程师同样合适。
  • 往下深扎技术,往上学习架构知识。IE 优化技巧会过期,但是浏览器渲染流程和算法不会过期; HTTP1.1 到 HTTP 2.0 过程中,协议会变化,但是定义问题,解决问题思路不会过期; iOS / Android 之上语言会转变,但是基础资源管理、IO 模式、TCP 协议不会过期

蚂蚁体验技术使用另外一种模式规避了这个问题,将前端概念从「端」扩展到「体验技术」。 格局一下子扩大,不再限于在用户浏览器运行,关注边界扩大到用户使用的方方面面。 他们推出的 语雀 Lark、AntDesign 以及背后支持的 Basement 开发者技术栈也确实给使用者带来更好体验, 加速了开发者速度,降低了前端工程师开发门槛,完整诠释了「体验技术」意义。 关于「体验技术部」故事,你可以看 那些年的体验技术部 - 知乎 了解更多。

后端天花板

后端开发工程师瓶颈是什么?我认为是业务理解,而业务理解抓手是数据理解。 最朴素业务理解是帮助产品经理梳理需求,将其所构想产品工程化实现出来。 但以更高要求来对待时候,单纯实现就远远不够了,要考虑成本和收益。 比如用户 Landing 页面优化,投入一周时间进行开发这是成本,那么期望到收益是什么? 更高的用户转化率。后端工程师是否有意识对这些数据进行建模、AB 测试、跟踪结果,进而帮助产品、运营进行决策?

除了完成功能,数据理解还有另外一个层面意义。在数据量规模到达一个量级时候,系统所追求不仅仅是可用、稳定, 还需要从沉淀数据中挖掘业务内在关系,将数据模型展现出来。这个工作内容已经超越了后端工程师职责, 属于数据工程师(还有一些叫法数仓管理员)职责。他们工作核心内容就是通过对业务数据挖掘,发现问题、解决问题,给予业务指导。 手段是建立体系化量化指标,将沉淀数据和日常业务关联。

后端是否可能被取代?我认为传统应用开发工程师被取代概率高,未来 10 年左右时间可以被取代。 为什么这么说,什么工种可以被取代?越标准化的工种越容易被取代。应用业务开发经过这些过程:

  1. 产品需求构思(产品经理拍脑子 / 数据决策)
  2. 需求分析
  3. 需求实现
  4. 测试
  5. 开发
  6. 上线运行

应用开发工程师参与了 2 3 4 5 6 部分, 每个部分产出物已经逐步呈现出标准化势态。比如需求分析文档+系统设计文档,已经具备标准化雏形(离岸外包也是基于这个来开发)。 进一步想,如果一门语言描述能力足够强,需求分析阶段即可将实现完成。4、5、6 也可以被自动化设施所取代。 应用开发工程师在整个工程师生态里面是手的存在,而非脑存在。手总是可以通过工具增强所替代。 我们设想一种场景,让业务方自己写 SQL,然后根据 SQL 生成标准化的 DAO 模块、Service 模块、View 模块、配套上合适的 UI 界面, 就可以拿出去直接用了。

后端如何才能不被取代呢? 在复杂度上面施力。复杂度可以往两个方向发展,对业务有更深刻理解成为业务专家。 支持大数据量和提供高可用性,成为基础设施专家,比如分布式存储、搜索、算法、芯片、网络、效能*。

另外一种升维办法是成为技术团队技术管理者,融合技术领导者和团队管理者两种技能。

总结

后端天花板更高,但之所以高并非语言等技术因素带来的,本质原因是贴合业务更近、需要处理数据更多、有状态并且需要长期提供服务。 前端突破天花板就不是前端,后端突破天花板就不是后端,不要被角色限定自己学习内容,不要给自己划定边界。

最后提一个问题,现在越来越火的 Serverless,如果后端来建设该如何建设?如果前端来建设该如何建设?


原文链接: https://blog.alswl.com/2019/07/frontend-backend-ceiling/
3a1ff193cee606bd1e2ea554a16353ee
欢迎关注我的微信公众号:窥豹

Comments

comments powered by Disqus