所谓理论上的“全栈”工程师，就是掌握各类技术，精通各门语言，熟悉各种框架的工程师，能够为项目铺设基础设施，能够设计系统架构，能够解决各种开源框架的问题，并把相应的框架知识带给团队。然而一个工程师的成长往往限制于很多因素，诸如时间、精力、专注度、自控力、天赋以及公司的业务倾向等等，注定了这样一位大神是不能够轻易诞生的。
全栈工程师应侧重于为项目筑基
事实上，很多案例已经证明，全栈工程师的工作往往是需要在项目前期展开的,而真正等到项目的生产线已经稳定，开发人员已经能够在基础框架和测试系统中开始稳定输出编码并测试时，往往也就意味着项目失去了对于全栈工程师的依赖。
究竟是怎样的场景提出了对于全栈工程师的需求？
这并不是一个容易理清的问题，之所以这么说，也是因为许多公司在不必要全栈工程师的时候，提出了招聘全栈工程师的需求。
近些年，随着客户对于计算机办公系统以及工业物联系统的深入调研，许多中小软件开发企业从原有的瀑布式管理转向了敏捷管理，无论处于主动亦或者被动情况，都让许多技术公司能够渐渐认清，真正好的适用的产品绝不是能够通过固定报价的方式得到的，传统的项目方式，越发不适应于当前的市场，糟糕的系统过程和UE设计足以让我们充分的认识到这样一点。
然而，转型到敏捷过程是一个痛苦的过程，即使对于一个有若干年敏捷经验的团队。仍旧在敏捷的过程中惹了一些不必要的苦恼。敏捷意味着快速迭代，也就意味着快速的需求变更。
对于架构来说，无法清晰的看到产品轮廓是敏捷项目的最大困扰，因为没有轮廓, 就没有充足的系统架构设计，快速的迭代变更，为系统架构带来了高昂的风险。因此持续演进的架构体系被引入进来, 然而这也没有完全摒除风险。此时，就需要一位技术经验丰富的全栈工程师来对项目进行保驾护航。
不必最好，只要最适应
对于大部分公司和项目经理来说，最关心的问题就是, 既然很难有真正意义上的全栈工程师，那么是否还需要大费周折去招聘呢?
其实这就回到了原始的部分，对于一个企业招聘，最重要的还是先确保明确自己的需求，如果说，在敏捷项目中, 我们预测到了高昂风险的迭代过程，那么招聘一个能够适合公司需求和企业文化的全栈工程师还是非常有必要的。
一个合格的全栈工程师,不仅仅能够解决技术和业务上的问题,往往也会给团队带来更多新技术的血液。这对于一个技术团队的建设具有很高的价值。
