上周末，被朋友拉去当了两天壮丁。起因是他们一个JAVA项目需要调用设备串口驱动，而他们的工程师无法解决一些问题。遂找到了我这个同样心里没底的外援。他们的工程师都大概是3-5年工作经验，都是比较不错的，那么面对这样一个项目，问题出在哪了？后来逐步发现，他们并没有真正意义的架构师，也就没有深入的技术调研和面向未来的系统集成架构方案。面对这样的业务场景，或许很多人想到的是，需要一名全栈工程师。在此之前，受朋友推荐，我跟另一家小企业的技术老大见了一面，他们同样表达了对于“全栈”工程师的需求。然而很多人之所以迷信“全栈”，其根本问题就是既不了解自己的业务场景，也不充分理解“全栈”二字。

所以，这里我们不妨聊聊。

1. 没有理论上的“全栈”工程师
这一点很好理解，所谓理论上的“全栈”工程师，就是掌握各类技术，精通各门语言，熟悉各种框架的工程师，能够为项目铺设基础设施，能够设计系统架构，能够解决各种开源框架的问题，并把相应的框架知识带给团队。然而一个工程师的成长往往限制于很多因素，诸如时间、精力、专注度、自控力、天赋以及公司的业务倾向等等，注定了这样一位大神是不能够轻易诞生的。就算真的有一个这样万里挑一的大神也很难落到一个中小型企业当中，而更可怕的是，如果一个中小型企业选择了这样的一个工程师，因为高昂的费用所以往往是自损元气。

这里不得不抱怨几句, 商业运营往往对技术认识有着可怕的导向性, 之前一个好朋友想通过一些培训机构加入到计算机这个行业, 对比了当时市场招聘的职位以及当时许多培训机构的说辞, 最终选择了一家面向"全栈工程师"的培训机构,然后几个月下来,当他去认真准备投递那些全栈工程师的岗位,他忽然发现自己悲剧了,因为到企业面试时发现,他所谓的全栈技术知识,远远达不到一个企业招聘这个岗位的标准,甚至不足以应付一个初级工程师的要求,由于培训机构要在短时间内对各种技术知识浅显的讲解,让他一些基本技术没能够深入掌握,无法达到一个正常开发者的基本技术要求. 我想这样的事例并不鲜见于此吧.

2. 全栈工程师要区别于系统架构师
如果你是一名项目经理,需要开发一套较为常规的ERP系统,那么你绝对不需要一名全栈工程师,一个前端加上几名后台工程师的开发团队足矣.

这个观点其实反应了一个信号, 那就是全栈工程师更为侧重于技术经验而非业务经验. 对于一个开发者, 往往是双线知识在同时推进, 一类是底层技术知识, 另一个是与实际业务相关的业务知识. 这个特点对于小的且敏捷的团队尤为明显. 因为针对客户的需求, 往往需要敏捷的工程师能够理解业务功能, 而只有站在业务功能的理解基础之上才能够明朗技术问题和技术解决方案. 然而在常规的团队中, 一个全栈工程师的能力往往不会表现出对应的业务知识, 而仅仅是技术能力. 它能够建立符合业务需求并且适当情况下设计符合持续演进要求的技术架构即可, 另外就是能够解决很多的技术问题. 如架构本身局限问题, 架构松耦合等问题.

然而这也并不意味着一个全栈工程师能够等同于系统架构工程师, 因为系统架构的设计除了适应技术要求外,更需要为对应业务开发提升效率而服务. 一个产品的系统架构师应主要关注于后者, 而在对应的场合中,将更多技术部分交给全栈工程师.

3. 全栈工程师应侧重于为项目筑基
事实上,很多案例已经证明, 全栈工程师的工作往往是需要在项目前期展开的,而真正等到项目的生产线已经稳定, 开发人员已经能够在基础框架和测试系统中开始稳定输出编码并测试时,往往也就意味着项目失去了对于全栈工程师的依赖.

这也就是利用各种事实案例明确了全栈工程师的工作, 即在新的业务上马的时候,我们绝对需要一个全栈工程师为项目铺设基础设施, 他能够熟练的使用Container, CI/DI等工具为项目架设工作流,并辅助架构师铺建基础的项目技术架构,在保证架构轻薄的同时,能够合理的解耦IO, 数据驱动, 事件驱动等部分的代码,并封装为易于常规开发者调用的API.这绝非是一项简单的工作, 前期架构的工作往往意味着其他开发者的开发效率,以及业务变化带来的重构问题的可能性. 虽然当前技术架构中,我们有微服务, 模块化, 面向对象以及面向函数,消息订阅发布系统等等松耦合的办法, 但并不意味着没有项目中后期重构的可能性.

4. 恰恰是敏捷项目提出了对于全栈工程师的需求
事实上,关于这个问题我思考了很多, 也想了很久. 究竟是怎样的场景提出了对于全栈工程师的需求. 这并不是一个容易理清的问题.之所以这么说,也是因为许多公司在不必要全栈工程师的时候,提出了招聘全栈工程师的需求.

从我个人的经历来看, 近些年,随着客户对于计算机办公系统以及工业物联系统的深入调研, 许多中小软件开发企业从原有的瀑布式管理转向了敏捷管理. 无论处于主动亦或者被动情况, 但都让许多技术公司能够渐渐认清,真正好的适用的产品绝不是能够通过固定报价的方式得到的. 传统的项目方式,越发不适应于当前的市场, 糟糕的系统过程和UE设计足以让我们充分的认识到这样一点.

然而,转型到敏捷过程是一个痛苦的过程, 即使对于一个有若干年敏捷经验的团队,仍旧在敏捷的过程中惹了一些不必要的苦恼. 敏捷意味着快速迭代,也就意味着快速的需求变更. 对于架构来说,无法清晰的看到产品轮廓是敏捷项目的最大困扰,因为没有轮廓, 就没有充足的系统架构设计, 快速的迭代变更,为系统架构带来了高昂的风险. 因此持续演进的架构体系被引入进来, 然而这也没有完全摒除风险.此时,就需要一位技术经验丰富的全栈工程师来对项目进行保驾护航.

在谈论本部分的时候,与上一个部分有一个小小的矛盾, 而这个矛盾也是敏捷项目带来的风险之一.即全栈工程师侧重于项目筑基的前期, 又需要长期的保驾护航. 这实际上是一个概率事件了. 根据个人过去的项目经验, 发现即使项目初期我们因为敏捷而对项目产生"盲目",但大多情况下,我们也不必为此过分担心. 然而概率发生时,如果没有一位优秀的工程师护航,其结果也是致命的.

很多时候一些公司找我去临时解决技术问题, 但这并不是一个负责的过程, 因为如果没有在解决问题之后完整的交接, 那么产品本身始终将处于高风险之中.

5. 不必最好，只要最适应
聊到此,其实也就没什么了,然而对于大部分公司和项目经理来说, 最关心的问题就是, 既然很难有真正意义上的全栈工程师,那么是否还需要大费周折去招聘呢?

其实这就回到了原始的部分, 对于一个企业招聘,最重要的还是先确保明确自己的需求, 如果说, 在敏捷项目中, 我们预测到了高昂风险的迭代过程, 那么招聘一个能够适合公司需求和企业文化的全栈工程师还是非常有必要的.

一个合格的全栈工程师,不仅仅能够解决技术和业务上的问题,往往也会给团队带来更多新技术的血液. 这对于一个技术团队的建设具有很高的价值。