漫谈前后端天花板
在阿里，我们不得不承认一个事实：前端的确有价值，但放在全局来看，前端产生的价值并非核心价值。 在阿里，虽然前端的工作已 经不可或缺，但对大公司而言，不可或缺的岗位多了去呢，不可或缺不代表有核心价值，我就不说了。
- 玉伯 2013 年 阿里前端的困局与突围
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。 随着大前端发展，这方面的空间已经大大扩充，Web / App 前端已经可以基于 Flutter / Electronic 等技术做 PC 端应用。 但这类应用数量较少，开发技能点和常见应用开发差异较大，不作为常规路线讨论。
我给前端同学的建议：
- 不要被手头事情限制住，也不要被 Title 限制住，开阔自己的技术视野，和上下游多合作，去理解上游业务和下游技术点。 这个建议对后端工程师同样合适。
- 往下深扎技术，往上学习架构知识。IE 优化技巧会过期，但是浏览器渲染流程和算法不会过期； HTTP1.1 到 HTTP 2.0 过程中，协议会变化，但是定义问题，解决问题思路不会过期； iOS / Android 之上语言会转变，但是基础资源管理、IO 模式、TCP 协议不会过期
蚂蚁体验技术使用另外一种模式规避了这个问题，将前端概念从「端」扩展到「体验技术」。 格局一下子扩大，不再限于在用户浏览器运行，关注边界扩大到用户使用的方方面面。 他们推出的 语雀 Lark、AntDesign 以及背后支持的 Basement 开发者技术栈也确实给使用者带来更好体验， 加速了开发者速度，降低了前端工程师开发门槛，完整诠释了「体验技术」意义。 关于「体验技术部」故事，你可以看 那些年的体验技术部 - 知乎 了解更多。
后端天花板
后端开发工程师瓶颈是什么？我认为是业务理解，而业务理解抓手是数据理解。 最朴素业务理解是帮助产品经理梳理需求，将其所构想产品工程化实现出来。 但以更高要求来对待时候，单纯实现就远远不够了，要考虑成本和收益。 比如用户 Landing 页面优化，投入一周时间进行开发这是成本，那么期望到收益是什么？ 更高的用户转化率。后端工程师是否有意识对这些数据进行建模、AB 测试、跟踪结果，进而帮助产品、运营进行决策？
除了完成功能，数据理解还有另外一个层面意义。在数据量规模到达一个量级时候，系统所追求不仅仅是可用、稳定， 还需要从沉淀数据中挖掘业务内在关系，将数据模型展现出来。这个工作内容已经超越了后端工程师职责， 属于数据工程师（还有一些叫法数仓管理员）职责。他们工作核心内容就是通过对业务数据挖掘，发现问题、解决问题，给予业务指导。 手段是建立体系化量化指标，将沉淀数据和日常业务关联。
后端是否可能被取代？我认为传统应用开发工程师被取代概率高，未来 10 年左右时间可以被取代。 为什么这么说，什么工种可以被取代？越标准化的工种越容易被取代。应用业务开发经过这些过程：
- 产品需求构思（产品经理拍脑子 / 数据决策）
- 需求分析
- 需求实现
- 测试
- 开发
- 上线运行
应用开发工程师参与了 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
欢迎关注我的微信公众号：窥豹
Tips: Until now, everytime you want to store your article, we will help you store it in Filecoin network. In the future, you can store it in Filecoin network using your own filecoin.
Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: