极客时间已完结课程限时免费阅读

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

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

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

讲述:四火

时长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比较
下一篇
全栈回顾 | 成为更好的全栈工程师!
unpreview
 写留言

精选留言(1)

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

    作者回复: 👍

    2