40 | 全栈衍化：让全栈意味着更多

Dec 11, 2019

40 | 全栈衍化：让全栈意味着更多-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

40 | 全栈衍化：让全栈意味着更多

2019-12-11 四火来自北京

《全栈工程师修炼指南》

课程介绍



讲述：四火

时长15:18大小10.49M



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

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 3

提建议

39 | XML、JSON、YAML比较

全栈回顾 | 成为更好的全栈工程师！

 写留言

精选留言(1)

leslie
2019-12-11
全栈其实就如老师开始的定位：万事皆会万事皆能，就像我们通常会说“万能的运维”；运维为何万能-其实就是因为知识的全栈，如同SRE一样，老师提及SRE时似乎漏了一块-DevOps，个人通过对全栈的梳理强化了开发和网络方面的根基。 Ops从业多年其实就更能切身感受到其中的问题：设备不多的话OPS的工作蛮鸡肋不如直接上云，多了就必须用自动化或者AI，不然的话事情做不完。11月国内GOPS 大会让我深深的感受到了OPS这种变革其实同样是我内心对这个职业切身的感受，尤其参会过程中的学习交流。 Google的SRE看完时就想到了书中提及的DevOps：那本书关于这块不知道是翻译的问题还是针对了特定场景，单纯的解释网站稳定工程师有疏漏。个人在学习的过程中同时在学DevOps，刚好可以把这些年Ops沉淀的东西用上。极客时间的<DevOps实战笔记>一直在同步跟着学习，算是后期自己的一个方向吧。
展开
作者回复: 👍
2

