柳州-遇湖西
早在我却是个小学生的这时候，就时常听见「全栈技师」的荣誉称号。那这时候就真的那个工作岗位很大很牛逼，其间端控制技术单厢，很大是合作开发人员中的人上上。
前面渐渐也听闻过，全栈技师事实上就是啥单厢点，但啥都不精，就跟我们理工学院黄金时代的这些专精那样。
看上去好似源远流长，但都而已通晓毛皮。那全栈呢两个说实话的事呢？
咱也但是多文章了，再说随著组织工作年数的提升，前段时间我也渐渐碰触并分担了一些有关全栈的合作开发组织工作，真的那个路径却是挺有趣的。
觉得是，没有合作开发人员人上人那么生硬，但须要掌控和兼及的控制技术点也确实是挺多的。
这儿归纳两个有关全栈技师的特征：
一、纪律性更重要
难道是全栈了，总之其间端控制技术单厢懂点，要不然什么样两个人甘当两个工程项目组呢。
但也千万别过分神格化那个身分，即便还没两个人能说自己能通晓后端或是后端控制技术的。
全栈技师更偏激只好两个分立合作开发人员，一切顺利不然能包办两个小工程项目中的大部份标识符成份。
主要包括后端UI渲染、组建封装、页面布局、数据请求以及必要的逻辑处理，还有后端接口封装、数据库设计、数据校验、服务构建以及架构设计等模块。
单从控制技术点上来说，确实是比单纯的后端技师或后端技师要了解得更多更全面。
我们都知道，在大型工程项目的协作合作开发中，沟通联调往往是最麻烦也是最累人的环节。
因为其间端同学会时常性的只站在自己单端立场和角度上去思考和规划接口以及控制技术方案的制定，这样就会导致方案缺乏整体的可行性。
所以相对来说，全栈技师能省去许多在沟通协作上花费的精力和时间，自己就能进行全链路的分析和方案制定。
在那个层面上来说，全栈技师所带来的整体工程项目风险上的评估把控，以及控制技术方案上的精简和融洽是单端技师无法比拟的。
所以在我看来，全栈技师所处的视角很大不是偏激于某一端，而是须要拥有两个全局的视角。从用户和控制技术人双重身分出发，全链路的审视和评测整个工程项目的。
许多后端合作开发会真的后端就是切切图画画UI，请求数据渲染下图表；很多后端也会真的后端就是对数据库的增删改查，到处调接口拼凑下数据返回。这其实都是因为想法比较片面所造成的。
对于两个全栈技师，更应该能区分其间端区别和所擅长的地方，在标识符构建上能将逻辑进行合理的划分。
比如后端就不该无脑透传，后端也不该做太多太重的数据处理的逻辑。在工程项目整体上避免头重脚轻。
二、适合小而美的工程项目
上面也提到过，全栈技师事实上相当于分立合作开发人员，相当于两个工程项目组。但按照我的理解，一名全栈技师其实并不适合去完成两个大型的工程项目。
全栈技师由于控制技术全面，所以无论是在学习成本却是合作开发精力上，都是比单端技师要高的。这就会导致大家的一种固有印象，“全栈就是杂而不精”。
虽然不能一棒子打死，一言以蔽之，但至少却是能说明全栈在实际的大型工程项目合作开发中，大概率单端能力是比不上单端技师的。
并且再加上由于人力成本和工程项目规划上的考虑，全栈更适合的是那种小而美的工程项目。而不是分分钟几亿日活的超级工程项目。
所以其实认识到这点之后，全栈能做的东西就很多了。在大厂中，全栈往往都不会参与巨无霸app主端合作开发组织工作，更多是在做各种平台建设以及效率工具的研制。
我们都知道大厂里内卷现象严重，很多这时候卷就卷在平台建设上。
各种类型相似的平台层出不穷，每个工程项目组想象向全部门甚至全公司推广自己内部的研制平台，之后就是各种开源的操作，以提升影响力。
所以千万千万别小看了做平台建设和效率工具研制的这群全栈。总之了，现在真正做平台的也不而已全栈技师了，只要会写点标识符的单厢来做平台。
什么其间端客户端测试测开，学点后端看下后端，两个个做的飞起。懂得都懂。
三、容易转控制技术管理
我们都知道，一般控制技术人的一大出路就是做控制技术管理。其实这就是当领导了。
现在互联网大厂里，特别是比较看重控制技术的公司，很多领导事实上都是控制技术出身转的管理层。
这样的方式的好处不言而喻，让懂控制技术的人来带控制技术工程项目组是最好但是的了。而两个稍微成熟点的控制技术工程项目组，都不会只有一种工作岗位的。
很多领导管理的都是主要包括后端后端测试测开等控制技术工作岗位的两个大工程项目组。
在这样工程项目组中，对领导的控制技术视野以及控制技术广度的要求是很高的。而一名全栈技师，天生就有这样的优势。
全栈从一开始，所处的视角就更为全面，从工程项目规划到控制技术方案，从风险评估到排期交付，全栈技师都拥有更靠近上帝的视角。
事实上就是偏领导的视角，这本质上对控制技术管理的组织工作的组织工作来说是有帮助的。
再加上全栈技师碰触的控制技术点更广，在控制技术上更侧重于广度，事实上也是理解和协作不同领域控制技术人的基础。
总之这而已从控制技术广度上来说明全栈技师拥有相对而言更全面的控制技术广度和相对高的控制技术视野。并不意味着全栈更容易得到晋升或是当领导。
即便，作为一个控制技术管理最重要的却是领导力和管理能力。更多的这时候却是须要时运和机会。
四、低标识符轻服务
上面也提到过，全栈更适合小而美的工程项目。在这样的前提之下，诞生了许多能帮助全栈技师快速搭建平台产物的工具。
比如最常见的就是只须要拖拽组件就能快速进行页面布局的后端工具，现在还有渐渐流行起来的可视化后台管理配置系统。
这些本质上都属于低标识符甚至是无标识符工具，只须要掌控基本的其间端理论就能快速搭建简易的平台。
在程序员已经成为劳动密集型的新型农民工的黄金时代背景下，这种低标识符平台能很容易想象到它在tob端用武之地。
除此之外，轻服务也是用来快速构建平台的有利工具。现在互联网大厂基本都离不开各种云服务，各家大厂也都在发力云服务器的研制的扩展。
因此基于各种成熟云服务器的轻服务也随之流行。轻服务相比于传统的后端框架，能提供开箱即用的合作开发体验。
合作开发人员无需考虑服务器和数据库等基础设施的搭建，更不用操心测试环境配置、数据备份和线上运维等一系列繁琐之事，只需专注于产品合作开发本身。
其实轻服务本质上就是相当于部署在云服务器上的容器，可以在容器中建立云函数云方法，甚至是云工程，合作开发人员自身不须要关心后端各种环境的搭建。
总之这样的方式更适用于轻量级的后端，像腾讯云和字节轻服务都是类似的所谓后端低标识符的实现方式。
所以对于全栈合作开发人员而言，低标识符和轻服务在很大程度上能帮助快速便捷的搭建平台。总之对于单端合作开发人员而言也可以很轻易的上手构建全栈工程项目。
全栈技师其实也不是什么十分高大上的工作岗位，相比于单纯的后端或后端技师，拥有更为广泛的控制技术视野和全局视角。而单端技师在现在的控制技术环境下，也能很容易的去做全栈的组织工作。
所以全栈技师的职业发展后期也须要保证控制技术广度的前提下，专攻两个路径，提升某个控制技术路径的控制技术深度。这样才能更长久。
就像我现在那样，做业务需求或控制技术重构都是用本职组织工作的控制技术栈，但在参与研制工具和研制平台的建设时，往往都是后端后端客户端一手抓的。
Python、JS/TS、C/C++、Java、Go、Ruby各种语言都是哪样顺手用哪样。
控制技术这种东西本身是不设限的，并且只要入了这行，就不可能说一直只写某一种语言，或是只用某两个控制技术栈。
在不同场景，不同需求背景以及不同产品上，能选择合适的语言，合适的框架，保持不断的学习才是持续进阶的基础。
或许，每两个合作开发人员都应该，并且都可以是两个全栈技师。
