而在那段时间中，全球的一线国际大厂，如谷歌微软，的招聘岗位中更多地有全栈的这一概念，更有甚者则只有全栈这一岗位。让全栈工程师的这一概念更加的神圣化。但是你有没有思考过这么一个问题，全栈相比一般的前端后端程序员来说，他们有什么样的优势？
全栈工程师的优势
全栈工程师，我们广义上的理解，一般理解成他对前端、后端、数据库以及运维操作都有所涉猎，并可以满足他对项目的开发、部署、上线与维护流程需要。概括来说，他一个人可以搞定一个需求。为什么会诞生这样的需求？
从结论上来讲，是为了追求更高的效率。
当一个人同时对软件周期的全流程都可以掌握的时候，那么他就可以对软件周期中产生的全部问题进行追踪、定位以及处理。减少了理解和学习的成本，避免了由于技术栈的不满足定位条件而导致的换人产生的沟通损耗。单个的人员可能不太明显，你不好评估全栈工程师和后端工程师的后端技术如何，或者与前端工程师相比他们的前端技术如何。这种比较是没有实际意义的。但是当产生规模的时候，比如一队的全栈工程师与一组混编的前后端同学组成的时候，那么他们的优势就体现出来了。全栈工程师在进行前端设计时了解后端数据库的实体设计；在进行后端设计的时候也了解前端的交互逻辑。那么对问题的思考就更加地全面。
我对全栈工程师的总结是: 面面俱到，减少损耗。
全栈真的是优势吗
上面说得看似合理。但就如同一开始说的，全栈的诞生是源于需求。在早几年的时候，MVC等结构还很流行的时候，工程项目经常是前后端一体的项目。对于这种项目无论是版本迭代还是特性交付，前后端的部分都是绑定在一起的，一荣俱荣一损俱损。后端为前端提供的是页面的跳转逻辑，这种数据的流转方式单独地抽离出来是没有商业价值的。只有前后端一起存在的时候才有商业价值。所以，前后端合一，项目部署合一，为了减少沟通的损耗，也就诞生了全栈的需求。
显然，这种格局被打破了。而打破它的则是我们现在耳熟能详的: 微服务。
微服务概念的诞生让一个条件发生了改变，就是刚刚说到的商业价值。微服务的概念让一个单独地提供某种特性功能的后端服务有了独立部署的商业价值。而从此之后，后端数据提供的接口概念并不仅仅是服务于页面的数据提供。而是向外提供一组满足业务特性的接口调用，他可以单独为页面、或者其他的后端服务提供具有商业价值的能力。
当这种情况出现了之后，我们就发现，前端能力和后端能力可以独立地进行部署（前后端分离）、迭代和评估交付。而后端因为将具有同一领域特性的服务进行抽离，而逐渐演进成了我们目前经常见到的这种框架：
前端 -> BFF(业务编排) -> 领域服务 -> 数据库
那我们就可以发现了，这种模式下的框架有几个特点，流程变长、软件数量变多（领域层可能会有很多的应用），且他们之间都是可以独立交付的。那么问题就是，在这种新的框架模式下，我们又该如何定义全栈呢？是否可以独立负责其中一个交付模块的人（客户端，领域服务）叫做全栈呢？还是将可以完整掌握这一套所有流程的人才叫全栈呢？实不论是哪种划分方式，我们就会发现，不论怎么划分，全栈工程师可能不会改变。但是真正改变的是非全栈的工程师，因为新的划分方式让他们即便是专精单独领域，也有了可以独立进行业务交付的能力。
全栈不是全能
如果你是一名开发人员，那么我想你可以轻松地理解上文中提到的内容。不过，其实有一点是偷换了概念的，那就是：全栈只是了解语言本身，并不是全知全能。
你可以试着回忆一下，当你进行一次需求开发的时候经历了哪些流程?产品从用户侧挖掘需求提炼概念进行prd编写，然后内部沟通 以及kickoff会，后续输出给PO。再者是任务分配与项目开发、测试、回归、验收、上线。大概流程可能如此，而涉及全栈概念的则只有“开发”、“测试”等几个过程。再试想一下，即便是两个已经在公司呆了多年的同事，但是在不同业务线，他们之间的业务对接是否就一定顺畅无阻？全栈仅仅是语言上的优势（甚至在精力上不算优势），但在业务沟通上来说，他们是和非全栈的开发人员是一样的。全栈并非全能，仍然是需要梳理需求，熟悉业务的。
所以，全栈可能有一些优势，但是在当前环境中这种优势逐渐变小甚至没有。而如果仅仅是全栈，但是沟通与交际能力不足的话，同样是不行的。
你是全流程工程师吗？全栈非万能。那么我们真正的痛点是什么呢？
咱们在最开始的时候提到，全栈的需求源于增效。那么我们在实际的业务需求中感觉最花费时间的是什么呢？
开发的本质
开发的本质是业务知识向工程知识的转化。
虽然可能是暴言，但是我在这里提供出一个概念，如果有不同意见可以讨论。这个说法更加通俗地说就是：设计->代码。这个设计可能是需求内容，也可能是UI设计。但是开发的本事就是一种诉求向工程的转变。如果你认为这个概念没有问题的话，那我就可以给出另一个概念。
开发效率与知识的转化速度正相关。
看起来像是没有说，但是这两个概念引出想表达的其实是：效率高低本身是和开发量本身无关的。重点是知识的转换与转化速度。举个我们经常开玩笑的例子就是，如果你能说服产品同学不做这个需求的话，那你的效率是最高的。尽管是玩笑，但却描述出了code只是手段，不是目的这一概念。
如果提高开发效率
如果说开发的本质是知识的转化的话，那么如果提高开发效率的这个问题，其实就可以换一个角度来描述，
如果提高知识的转化效率。
针对这个问题，我们可以再看一遍平时工作时候的流程。产品从用户了解需求，生成prd拉会，需求讨论，开发测试上线。我们可以发现，整个流程其实是知识的互相转化的过程。从用户背景支持，转化成了需求知识；从需求知识转化为了工程知识，然后上线。
一般我们在进行开发工作的时候，其实主要关注的是后面的需求转化为工程知识的过程。但是这就牵扯到两个问题：
需求并不是原始知识工程知识并不是最终目的这两个问题的另一种表达方式是：需求是用户提的，软件是用户用的。从用户来，到用户去，用户第一。这就是为什么开发同学有时候辛辛苦苦的加班加点的开发完毕后，结果用户不满意或者项目的实现效果也不好。因为这种知识的转化，和最终目的之间是有失真的。仅仅功能上线并不是需求的结束，满足用户的需求后才是最后的目的。那么这针对失真的调整，或者针对失真原因的学习才是开发中最消耗时间的。
针对这个问题，答案就很显而易见了：如果一开始就了解背景知识，那么自然开发效率就提高了。
全流程工程师
通过上文，想必你已经猜到了。根据以上的描述，如果开发同学可以掌握需求产生的完整生命周期的话，那他自然对于不同知识之间的转化就更加准确，而最后项目上线时的失真也自然会小很多。
你可以回想一下，各个项目组中是否有各种各样五花八门的历史包袱。无论是业务的，还是代码的，当你第一次踩坑的时候痛哭流涕的结果的过程中，这时候假如同事过来跟你说：“这是由于之前业务方的一个特殊的需求导致的。”。你会是什么心情？而这正是全流程工程师。
区别于全栈工程师是针对前后端不同技术领域提出的概念。全流程工程师是针对覆盖业务迭代流程的能力而描述的。也就是说：
全流程工程师具有从用户需求产生一直到项目上线用户反馈的全部知识。
针对这个概念，各位可能第一个想到的就是公司中的各种老鸟们。但确实是这样的。全流程工程师因为本身具有极高的业务知识储备，可以单兵为团队赋能。并且减少团队中项目失真的程度。并且因为对领域知识十分了解，在团队进行扩张或者重构的时候也是十分重要的角色。
如何成为全流程工程师
大家公司中也有很多时间超长的老人，可能尽管学习能力一般，但是经过长时间的学习过程，他们也在团队中担任全流程工程师这一角色。
但这样的同事在业务转型的时候往往就很难跟上了。所以我认为：全流程工程师需要较快的学习速度，且在快速学习领域知识的情况下串联起不同业务之间的联系，善于将分散的各个领域模块组装成具有统一语义的业务模型。
如果你是团队leader的话，我觉得可以留意这样的员工，他们可以提高团队的产出。
如果你是踏入职场不久的新人的话，大家可以尝试根据需求构建功能用例，然后将多个需求的用例串联起来，会是一个不错的了解需求背景的方法。
最后全流程工程其实是和全栈不冲突的，但是在前后端分离和微服务化的今天，我觉得全流程工程师的这个概念对评估一位开发来说更加地重要。同时本文的概念源自Thoughtworks中国区CTO徐昊老师的分享，如果大家对这个概念感兴趣可以自己搜索观看。
