从后端研发到全栈开发，是不是最美逆行者？

桂林-遇龙河

早在我还是个学生的时候，就经常听到「全栈工程师」的称号。那时候就觉得这个岗位一定很牛逼，前后端的技术都会，一定是程序员中的人上上。

后面慢慢也听说过，全栈工程师实际上就是啥都会点，但啥都不精，就跟我们大学时代的那些专业一样。

看起来好像博大精深，但是都只是略懂皮毛。那全栈是不是一个扯淡的事呢？

咱也不过多评论了，反正随着工作年限的提高，最近我也逐渐接触并承担了一些关于全栈的开发工作，觉得这个方向还是挺有意思的。

感觉是，没有程序员人上人这么夸张，但是需要掌握和涉猎的技术点也的确是挺多的。

这里总结几个关于全栈工程师的特点：

一、大局观更重要

既然是全栈了，当然前后端的技术都会懂点，不然怎样一个人充当一个团队呢。

但是也不要过于神化这个身份，毕竟还没几个人能够说自己能够精通前端或者后端技术的。

全栈工程师更倾向于是一个独立开发者，不出意外的话能够包揽一个小项目中的所有代码成分。

包括前端的UI渲染、组建封装、页面布局、数据请求以及必要的逻辑处理，还有后端的接口封装、数据库设计、数据校验、服务构建以及架构设计等模块。

单从技术点上来说，的确是比单纯的前端工程师或后端工程师要了解得更多更全面。

我们都知道，在大型项目的协作开发中，沟通联调往往是最麻烦也是最累人的环节。

因为前后端同学会经常性的只站在自己单端的立场和角度上去思考和规划接口以及技术方案的制定，这样就会导致方案缺乏整体的可行性。

所以相对来说，全栈工程师能够省去许多在沟通协作上花费的精力和时间，自己就能够进行全链路的分析和方案制定。

在这个层面上来说，全栈工程师所带来的整体项目风险上的评估把控，以及技术方案上的精简和融洽是单端工程师无法比拟的。

所以在我看来，全栈工程师所处的视角一定不是倾向于某一端的，而是需要拥有一个全局的视角。从用户和技术人双重身份出发，全链路的审视和评测整个项目的。

许多后端开发会觉得前端就是切切图画画UI，请求数据渲染下图表；很多前端也会觉得后端就是对数据库的增删改查，到处调接口拼凑下数据返回。这其实都是因为想法比较片面所造成的。

对于一个全栈工程师，更应该能够区分前后端的区别和所擅长的地方，在代码构建上能够将逻辑进行合理的划分。

比如后端就不该无脑透传，前端也不该做太多太重的数据处理的逻辑。在项目整体上避免头重脚轻。

二、适合小而美的项目

上面也提到过，全栈工程师实际上相当于独立开发者，相当于一个团队。但是按照我的理解，一名全栈工程师其实并不适合去完成一个大型的项目。

全栈工程师由于技术全面，所以无论是在学习成本还是开发精力上，都是比单端工程师要高的。这就会导致大家的一种固有印象，“全栈就是杂而不精”。

虽然不能一棒子打死，一言以蔽之，但是至少还是能够说明全栈在实际的大型项目开发中，大概率单端能力是比不上单端工程师的。

并且再加上由于人力成本和项目规划上的考虑，全栈更适合的是那种小而美的项目。而不是分分钟几亿日活的超级项目。

所以其实认识到这点之后，全栈能够做的东西就很多了。在大厂中，全栈往往都不会参与巨无霸app主端的开发工作，更多是在做各种平台建设以及效率工具的研发。

我们都知道大厂里内卷现象严重，很多时候卷就卷在平台建设上。

各种类型相似的平台层出不穷，每个团队想象向全部门甚至全公司推广自己内部的研发平台，之后就是各种开源的操作，以提升影响力。

所以千万不要小看了做平台建设和效率工具研发的这群全栈。当然了，现在真正做平台的也不只是全栈工程师了，只要会写点代码的都会来做平台。

什么前后端客户端测试测开，学点前端看下后端，一个个做的飞起。懂得都懂。

三、容易转技术管理

我们都知道，一般技术人的一大出路就是做技术管理。其实这就是当领导了。

现在互联网大厂里，特别是比较看重技术的公司，很多领导实际上都是技术出身转的管理层。

这样的方式的好处不言而喻，让懂技术的人来带技术团队是最好不过的了。而一个稍微成熟点的技术团队，都不会只有一种岗位的。

很多领导管理的都是包括前端后端测试测开等技术岗位的一个大团队。

在这样团队中，对领导的技术视野以及技术广度的要求是很高的。而一名全栈工程师，天生就有这样的优势。

全栈从一开始，所处的视角就更为全面，从项目规划到技术方案，从风险评估到排期交付，全栈工程师都拥有更靠近上帝的视角。

实际上就是偏领导的视角，这本质上对技术管理的工作的工作来说是有帮助的。

再加上全栈工程师接触的技术点更广，在技术上更侧重于广度，实际上也是理解和协作不同领域技术人的基础。

当然这只是从技术广度上来说明全栈工程师拥有相对而言更全面的技术广度和相对高的技术视野。并不意味着全栈更容易得到晋升或者当领导。

毕竟，作为一个技术管理最重要的还是领导力和管理能力。更多的时候还是需要时运和机会。

四、低代码轻服务

上面也提到过，全栈更适合小而美的项目。在这样的前提之下，诞生了许多能够帮助全栈工程师快速搭建平台产物的工具。

比如最常见的就是只需要拖拽组件就能够快速进行页面布局的前端工具，现在还有慢慢流行起来的可视化后台管理配置系统。

这些本质上都属于低代码甚至是无代码工具，只需要掌握基本的前后端理论就能够快速搭建简易的平台。

在程序员已经成为劳动密集型的新型农民工的时代背景下，这种低代码平台能够很容易想象到它在tob端的用武之地。

除此之外，轻服务也是用来快速构建平台的有利工具。现在互联网大厂基本都离不开各种云服务，各家大厂也都在发力云服务器的研发的扩展。

因此基于各种成熟云服务器的轻服务也随之流行。轻服务相比于传统的后端框架，能够提供开箱即用的开发体验。

开发者无需考虑服务器和数据库等基础设施的搭建，更不用操心测试环境配置、数据备份和线上运维等一系列繁琐之事，只需专注于产品开发本身。

其实轻服务本质上就是相当于部署在云服务器上的容器，可以在容器中建立云函数云方法，甚至是云工程，开发者自身不需要关心后端各种环境的搭建。

当然这样的方式更适用于轻量级的后端，像腾讯云和字节轻服务都是类似的所谓后端低代码的实现方式。

所以对于全栈开发者而言，低代码和轻服务在很大程度上能够帮助快速便捷的搭建平台。当然对于单端开发者而言也可以很轻易的上手构建全栈项目。

全栈工程师其实也不是什么十分高大上的岗位，相比于单纯的前端或后端工程师，拥有更为广泛的技术视野和全局视角。而单端工程师在现在的技术环境下，也能够很容易的去做全栈的工作。

所以全栈工程师的职业发展后期也需要保证技术广度的前提下，专攻一个方向，提升某个技术方向的技术深度。这样才能更长久。

就像我现在一样，做业务需求或技术重构都是用本职工作的技术栈，但是在参与研发工具和研发平台的建设时，往往都是前端后端客户端一手抓的。

Python、JS/TS、C/C++、Java、Go、Ruby各种语言都是哪样顺手用哪样。

技术这种东西本身是不设限的，并且只要入了这行，就不可能说一直只写某一种语言，或者只用某一个技术栈。

在不同场景，不同需求背景以及不同产品上，能够选择合适的语言，合适的框架，保持不断的学习才是持续进阶的基础。

或许，每一个开发者都应该，并且都可以是一个全栈工程师。