认识达内从这里开始

全栈工程师是随着互联网的不断发展而被提出来的一个新的岗位类型，下面我们就通过案例分析来了解一下，全栈工程师的优势与作用分析。

全栈工程师，我们广义上的理解，一般理解成他对前端、后端、数据库以及运维操作都有所涉猎，并可以满足他对项目的开发、部署、上线与维护流程需要。概括来说，他一个人可以搞定一个需求。为什么会诞生这样的需求?

从结论上来讲，是为了追求更高的效率。

当一个人同时对软件周期的全流程都可以掌握的时候，那么他就可以对软件周期中产生的全部问题进行追踪、定位以及处理。减少了理解和学习的成本，避免了由于技术栈的不满足定位条件而导致的换人产生的沟通损耗。单个的人员可能不太明显，你不好评估全栈工程师和后端工程师的后端技术如何，或者与前端工程师相比他们的前端技术如何。这种比较是没有实际意义的。但是当产生规模的时候，比如一队的全栈工程师与一组混编的前后端同学组成的时候，那么他们的优势就体现出来了。全栈工程师在进行前端设计时了解后端数据库的实体设计;在进行后端设计的时候也了解前端的交互逻辑。那么对问题的思考就更加地全面。

上面说得看似合理。但就如同一开始说的，全栈的诞生是源于需求。在早几年的时候，MVC等结构还很流行的时候，工程项目经常是前后端一体的项目。对于这种项目无论是版本迭代还是特性交付，前后端的部分都是绑定在一起的，一荣俱荣一损俱损。后端为前端提供的是页面的跳转逻辑，这种数据的流转方式单独地抽离出来是没有商业价值的。只有前后端一起存在的时候才有商业价值。所以，前后端合一，项目部署合一，为了减少沟通的损耗，也就诞生了全栈的需求。

显然，这种格局被打破了。而打破它的则是我们现在耳熟能详的:微服务。

微服务概念的诞生让一个条件发生了改变，就是刚刚说到的商业价值。微服务的概念让一个单独地提供某种特性功能的后端服务有了独立部署的商业价值。而从此之后，后端数据提供的接口概念并不仅仅服务于页面的数据提供。而是向外提供一组满足业务特性的接口调用，他可以单独为页面、或者其他的后端服务提供具有商业价值的能力。

当这种情况出现了之后，我们就发现，前端能力和后端能力可以独立地进行部署(前后端分离)、迭代和评估交付。而后端因为将具有同一领域特性的服务进行抽离，而逐渐演进成了我们目前经常见到的这种框架：

前端->BFF(业务编排)->领域服务->数据库

那我们就可以发现了，这种模式下的框架有几个特点，流程变长、软件数量变多(领域层可能会有很多的应用)，且他们之间都是可以独立交付的。那么问题就是，在这种新的框架模式下，我们又该如何定义全栈呢?是否可以独立负责其中一个交付模块的人(客户端，领域服务)叫做全栈呢?还是将可以完整掌握这一套所有流程的人才叫全栈呢?实不论是哪种划分方式，我们就会发现，不论怎么划分，全栈工程师可能不会改变。但是真正改变的是非全栈的工程师，因为新的划分方式让他们即便是专精单独领域，也有了可以独立进行业务交付的能力。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。