漫谈前后端天花板

不老的天空

在阿里，我们不得不承认一个事实：前端的确有价值，但放在全局来看，前端产生的价值并非核心价值。 在阿里，虽然前端的工作已 经不可或缺，但对大公司而言，不可或缺的岗位多了去呢，不可或缺不代表有核心价值，我就不说了。
- 玉伯 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，如果后端来建设该如何建设？如果前端来建设该如何建设？
<hr/>
原文链接:https://blog.alswl.com/2019/07/frontend-backend-ceiling/
3a1ff193cee606bd1e2ea554a16353ee
欢迎关注我的微信公众号：窥豹

程超

你这是要引战啊 233

蓝心萦梦

我觉得已经很中肯了

鼻屎噶的滑滑丹

那我问句不该问的！php是不是最好的语言！

伴糖

后端 更贴近业务和技术底层

啸月残狼

业务专家还属于后端不

别忘了我

层级往上走会有些模糊，但一般技术出生的应用研发不会特别纯粹业务专家。纯粹业务专家出身一般是金融、律师等领域专家。

诚挚李

也就是说，后端程序员对业务的了解和深入，不会导致四不像的尴尬地位，比如技术比不过专业的或者业务比不过专家，而是仍然有很好的空间和需求是吗。

李迎恺

当足够细分之后，就有空间和需求。

潇洒的土雷

知识量越大让业务跑起来所必须的点越多，天花板越高