|
|
# 40 | 全栈衍化：让全栈意味着更多
|
|
|
|
|
|
你好，我是四火。
|
|
|
|
|
|
专栏更到这里，我们已经把基于 Web 全栈的这棵大树，主要的枝枝丫丫大致都覆盖到了，可是，技术上我们总是希望“更进一步”。这棵大树所在的森林中，还有着广阔的领域等待着探索。当然，我想明确的是，我知道很多程序员还是会继续坚持这条路，因为全栈工程师本身是一个非常理想的职业发展方向，毕竟这个角色，大厂招，创业小团队更是需要；但同时我也知道，也有很多走在 Web 全栈路上的工程师，有着更多的想法，想尝试不一样的“可能性”，而这，就是我想说的个人的“全栈衍化”了。
|
|
|
|
|
|
## 个人
|
|
|
|
|
|
不知道你是否能记得起，我在这个专栏的 [\[开篇词\]](https://time.geekbang.org/column/article/134212) 中说到了关于全栈工程师的职业延伸，特别是在有了相当的积累的时候，比如工作接近五年、十年的时候，很多程序员都会对自己有更深刻的认识，更明确自己需要什么，喜欢什么。Web 全栈技术中，他们更愿意深挖某一个具体的领域；或是跳出了这个圈子，看上了另外的一棵技能树。也就是说，他们将全栈工程师作为自己的基础铺垫和视野拓展，从而成就职业进一步发展的跳板，毕竟，“有了全栈工程师的底子，未来面对软件行业进一步细化，选择其它细分职业时，会因为有了全面而扎实的基础而更有利”。
|
|
|
|
|
|
### 纵向：深挖 Web 的一个领域
|
|
|
|
|
|
如你所见，Web 全栈工程的覆盖面已经很广了，然后你再有了足够的积累，既包括项目的积累，又包括个人技术、非技术能力上的积累。但同时，如果你也发现，自己更喜爱某一个特定的子领域，那么这时候，是可以花一点时间，静下心来，想一想是不是可以细化自己的职业发展通道了。下面我来举两个纵向技术衍化的例子，希望给你一点启发：
|
|
|
|
|
|
**1\. 前端工程师**
|
|
|
|
|
|
前端工程师是全栈衍化一个最常见的去向之一，当然，反过来的案例也许更多（从前端工程师到全栈）。我们在第三章一开始已经提到了，由于前端技术的特殊性，比方说，前端领域的思维模式有着显著的特殊性（参见 [\[第 14 讲\]](https://time.geekbang.org/column/article/145875)），Web 领域的工作细分很早，就从独立出前端作为开始，发生了。
|
|
|
|
|
|
由于工作和项目的关系，我接触过不少不同背景的前端工程师，或是类似的角色（这个名称在不同的企业中有不同的称呼，比如 Amazon 它叫做 WDE，Web Development Engineer），但是总体来说，有着扎实的全栈工程底子的前端工程师，还是明显地显露出，很不一样的认识问题的视野和思考角度。比方说，定位一个用户访问响应时间的问题，这样的工程师很擅长从整个请求响应的完整链路分层去剖析；再比如说，代码设计和组织，他们在分层和模块化方面，相对而言，有着普遍扎实的基础。
|
|
|
|
|
|
**2\. SRE**
|
|
|
|
|
|
SRE（Site Reliability Engineer，网站可靠性工程师），这个角色最早很可能是 Google 创造出来的，从名称上也可以看出，这个职位的工程师所致力于解决的问题，就是网站可靠性的问题，这里的“可靠性”，包括可用性、延迟、容量等多个方面。他们就像是医院里的主刀大夫和急诊科医生，这是一个综合能力要求颇高的职位，也是一个绝对“实战”的职位，因为他们要面对的，都是大流量的网站等 Web 服务，都是一点点小问题都可能带来巨大经济损失的场景。
|
|
|
|
|
|
因此 SRE 需要尽力确保服务每分每秒的正常运行，他们的扮演的角色可远不只是“救火队长”，在“时间就是金钱”的压力环境下，严谨而大胆，快速定位和解决问题，但更重要的是，帮助不同的团队“防患于未然”，比如主导和把关新建服务的可靠性设计。SRE 有时要解决基础设施的问题，有时要分析服务端的压力来源，有时则要搞定网页上造成大量用户访问困难的“小 bug”。很显然，一个狭窄领域知识的工程师，是不可能胜任这样的岗位的，对于从端到端俯瞰整个流程的能力，Web 全栈工程师有着天然的优势。
|
|
|
|
|
|
### 横向：点亮另一棵技能树
|
|
|
|
|
|
下面再来看另一种分类，如果你发现自己的兴趣或是专长，并不在 Web 全栈领域方面，而是跃跃欲试地盯上了软件技术领域的另外一类角色，那其实也是一件可喜可贺的事情。毕竟，越早明确自己的兴趣和专长，在职业中做出变更的决定，就越能帮助自己接近目标，这其实有点像 RPG 游戏中的转职了。下面我就来举几个横向衍化的例子：
|
|
|
|
|
|
**1\. 数据方向**
|
|
|
|
|
|
这里的数据未必指大数据。如果我们退回到 10 年前，数据所扮演的角色，远没有当今的软件行业这样重要。如果你在 Web 全栈的学习过程中发现，自己对于数据有着超乎平常人的敏感度，或者对于数据本身所蕴含的事实原理充满兴趣，那么有一些和数据密切相关的职业角色，可能会成为你未来职业发展的一个好的选择。
|
|
|
|
|
|
比如说数据科学家（Data Scientist）、数据分析师（Data Analyst）和商业智能工程师（Business Intelligence Engineer），其中的前两者，我在 [\[第 20 讲\]](https://time.geekbang.org/column/article/154696) 中有过介绍。这些角色，都需要具备相当的数据分析能力，掌握一定的统计知识。全栈工程师的背景，能让你在胜任这样的角色的时候，具备更综合的工程能力，从而脱颖而出。比如你可以更容易地设计和改进数据分析工具，比如你已经掌握了一定的数据可视化技术（参见 [\[第 18 讲\]](https://time.geekbang.org/column/article/152557)），就可以迅速地将实现方案落地。
|
|
|
|
|
|
**2\. 系统方向**
|
|
|
|
|
|
这部分往往来自于对软件系统有着更高追求的工程师，这个方向在横向衍化中具备着相当的比例，比如，有一些软件工程师职位，从职责上看，其实和 Web 全栈工程师没有本质上的区别，但是因为其所涉及的项目、产品和技术领域独立在传统的 Web 之外，我就把它们单独拿出来介绍了。
|
|
|
|
|
|
我觉得这一点可以以我自己为例，我这几年所呆的团队，开发和维护的产品中，都包括典型的分布式系统。两年前是一个分布式计算平台，Amazon 所有产品的成本和利润就是在它上面完成计算的；如今在 Oracle 则是一个分布式工作流引擎。老实说，它们都和传统的 Web 全栈没有什么“直接关系”，但是正如我在专栏开始的时候所说，技术都是相通的，从全栈领域学到的那些套路和方法，可以帮助我在新的软件领域上手那些新技术。
|
|
|
|
|
|
我知道很多程序员朋友，从远期看都想成为架构师，比如平台架构师，解决方案架构师等等。但凡谈及“架构”基本上都意味着一个模糊的、足够大的领域。在我所了解的那些互联网巨头中，这些高级研发职位都要求跨团队、跨项目的技术决策和合作，很难想象一个狭窄领域诞生一个架构师级别的角色，而这一点，又得益于我们如今学得广、学得杂而夯实的基础。
|
|
|
|
|
|
**3\. 产品经理**
|
|
|
|
|
|
产品经理可以说也是一个非常常见的方向，产品经理和程序员之间相爱相杀的故事，已经“烂大街”了。“土生土长”的产品经理的比例其实不算太高，很多公司的产品经理都是从不同的岗位转过来的。比如运维岗，这样的产品经理，往往会额外地关注产品的可靠性以及运维的难度，毕竟他们是从这条路走过来的，深知其重要性。
|
|
|
|
|
|
同样的，有着全栈工程师背景的产品经理，显然更能够从工程的角度出发，去理解需求的实现，理解用户交互过程背后的原理，撰写更优秀的非功能需求的产品设计文档，也可以轻而易举地做出 HTML 快速原型。
|
|
|
|
|
|
## 项目和团队
|
|
|
|
|
|
上面我只是从个人角度介绍了全栈的衍化，这也是最常规的思路。但是，我们也完全可以从更多的角度来审视这个概念，比如说项目和团队。
|
|
|
|
|
|
在这里我想说的全栈项目，是指能够从不同的软件领域和软件技术的角度，覆盖端到端需求并解决问题的项目或项目集合，这里未必指单个的项目，而可以是多个关联项目所组成的集合；相应的，全栈团队，其实我在 [\[第 20 讲\]](https://time.geekbang.org/column/article/154696) 中已经介绍过了，是指一个团队具备较多方面、较多层次的技能，联合协作，去解决某一个领域的问题。
|
|
|
|
|
|
为什么要讲这个？因为我们整个专栏都在专注于 Web 全栈工程技能这一点上，但是我不希望在专栏之后，因为它而给你造成了思考的禁锢。我想学到了今天，你已经对于程序员掌握全栈技能的优势有了自己的理解，可是这一部分，完全可以衍化到项目和团队这样的维度上。
|
|
|
|
|
|
### 我自己的故事
|
|
|
|
|
|
在我工作的最初几年，虽然已经是一个全栈工程师了，个人技术上虽然收获很大，但是并没有产生这一个层次的认识。直到我加入了 Amazon，它的工程师文化对我之后的成长产生了很大的影响，也就是从那时候开始，我有了对于全栈项目和全栈团队的思考。
|
|
|
|
|
|
拿我自己来举一个例子，我曾经在销量预测团队中工作，我们整个团队五十余人，用一句话来 粗略地概括我们每天的工作，就是给几千万的商品预测销量。显然这就是一个全栈的大项目，里面有十几、二十个不同领域的小项目，包括销量预测的计算平台、高可用数据分发服务、数据同步服务、预测数据的序列化和存储服务，数据分析的可视化工具、预测统计和健康监控系统等等。
|
|
|
|
|
|
因此，从项目的多样性，你就能够想象团队角色的多样性（具体内容请参见 [\[第 20 讲\]](https://time.geekbang.org/column/article/154696)）。团队中有着许许多多擅长不同领域的角色，包括软件工程师、数据科学家、数据分析师、产品经理和支持工程师等等。而单说我们最熟悉的软件工程师，就具备着不同背景、不同专长，比如有擅长 MR 相关框架和技术的负责计算平台的工程师，有维护高可用数据分发服务的工程师，也有熟悉 Web 前后端开发的负责数据可视化的工程师等等。
|
|
|
|
|
|
后来我又加入了成本核算团队，项目也好，团队也好，技术也罢，虽然存在很大不同，可全栈的特性却是一致的。比方说，MR 的框架和工具从 Hadoop 系变成了 Spark 系，主要编程语言从 Java 变成了 Scala，工作流引擎从一个老旧的自研引擎服务变成了一个基于 SWF（Simple Work Flow）开发的在公司“内部开源”的新产品（即便放到今天来说，我依然觉得，它的共享资源管理等某几个核心功能，还是要比如今市面上我见到的都要优秀一些）……可是那又怎样，项目依然包含多个层次、不同的类别，而团队则依然包含类似分类的、多样的角色。
|
|
|
|
|
|
### 优势
|
|
|
|
|
|
在我看来，一个全栈的项目和团队，至少可以具备这样几个优势：
|
|
|
|
|
|
1.从多样的角度出发，提供完整的解决方案。
|
|
|
|
|
|
正如同销量预测团队中，预测一个产品的销量是一个极端困难的事儿，需要多种机器学习的模型配合工作，对于不同类型的商品，应用不同的数学模型；而数据的获取、计算、分发……这些又都需要软件来完成；数据的清洗、转换、分析又需要多种数据和统计知识，配合合适的工具来做到。对于一个角色单一的团队或项目，显然是无法做到这样一个复杂的过程的。
|
|
|
|
|
|
2.具备包容的团队，为不同特长和兴趣的人才提供创造价值的平台。
|
|
|
|
|
|
3.保持整体上健康和多样的思考角度，保证团队和产品的均衡发展。
|
|
|
|
|
|
每年我们都会举办 Hackathon，大致就是，团队成员可以提出创意、“招兵买马”，完整的两、三天时间，自发组织小团队，团队里有产品经理、工程师和数据分析师等等不同角色，一起把这个创意做出快速原型。其中优秀的一部分会成为未来一年真正的项目和产品。各种创意火花碰撞，这是我最喜欢的一个地方。
|
|
|
|
|
|
## 总结思考
|
|
|
|
|
|
今天我聊了聊 Web 全栈工程师在完成核心技术的修炼之后，可以考虑的下一步和进一步的方向，也就是个人的全栈衍化；也从项目和团队的角度，讲了全栈的优势和重要性。
|
|
|
|
|
|
不知道正在阅读的你，关于这方面，从职业规划的角度看，你的思路是怎样的，能简单分享一下吗？
|
|
|
|
|
|
## 扩展阅读
|
|
|
|
|
|
* 关于 SRE 这个角色，你可以参看 Google [自己的描述](https://landing.google.com/sre/)，以及 SRE 这个[词条](https://en.wikipedia.org/wiki/Site_Reliability_Engineering)。
|
|
|
* 关于文中提到的 Hackathon，想了解更多的话，你可以阅读[这个](https://en.wikipedia.org/wiki/Hackathon)内容。
|
|
|
|