代码学习无止境,程序员如何规划自己的职业生涯发展?

原创
08/19 16:40
阅读数 2.9K

圆桌议题


  • 议题一:开源自 2020 年开始列入国家规划后,开源项目越来越多。开源项目的涌现,为大家提供了学习和深度了解升级项目的途径。从学习的角度来看,一个开发者如何参与项目、学习项目?
  • 议题二:CloudWeGo 开源项目主要方向是云原生微服务框架, 这类项目主要的使用场景是什么样的?学习这类项目的价值点在哪里?混迹社区有什么经验分享?
  • 议题三:程序员作为项目使用者的角色,开发者作为开源项目设计者的角色, 这两种角色关注的点有什么不同?作为一个经历过这类角色转换的社区 Committer 来说,有什么经验可以分享?
  • 议题四:在社区视角和全局角度下, 谈一谈为什么大厂都在招聘 Go 工程师?程序员应该如何规划自己的职业发展?程序员最终的归宿是哪里?
  • 议题五:大佬分享环节,大佬们关注的博主/学技术的网站/书籍推荐。

嘉宾


议题一


开源自 2020 年开始列入国家规划后,开源项目越来越多。开源项目的涌现,为大家提供了学习和深度了解升级项目的途径。 从学习的角度来看,一个开发者如何参与项目、学习项目?

分享人:王伟超


关于这个问题的介绍主要从以下四个方面展开:
  1. 如何与 Kitex、CloudWeGo 社区结缘;
  1. 个人关于云原生和开源文化的认识;
  1. 为什么要参与开源以及我理解的开源精神;
  1. 个人以后对开源的想法。

如何与 KitexCloudWeGo 社区结缘

其实与 Kitex 的结缘是非常巧合的,虽然做了几年后端开发,但是感觉在技术上还是存在一些瓶颈,因此想要提升自己。回顾一下本人的过往经历:
  • 2021 年 9 月尝试在 InfoQ 做输出,挑战日更,更多是做翻译;
  • 10 月底决定学一点特定的技术,发现之前自己学习的更多是“道”和“法”层面,主要关于编程理念的知识和理解,很少关于“术”和“器”;
  • 联想孔子的一句话:“吾尝终日不食,终夜不寝,以思,无益,不如学也”,就是之前都是思维层面和架构层面的思考,不如学点具体的技术。因此,我决定再找一个话题,从感兴趣的方面入手,但是 Docker、云原生、架构设计、微服务思考这些话题非常火热且竞争很大,可能一时难以入手做出自己的东西;
  • 想起刚刚开源的 Kitex ,以及刚开源的 CloudWeGo 项目中相关的一些中间件集合的资料和实践应该比较少,于是开始了《CloudWeGo 微服务实践》系列,做了一个小的集合,但是也没写完整,只是写到了操作数据,不是一个完全的业务实践。
对我个人而言,了解微服务框架是一个很好的入门,并且更重要的是能够参与到社区中来。我在了解框架的过程中,经常在 CloudWeGo 飞书群了解相关动态,看一下 CloudWeGo 相关的 PR 或者 issue,关注一些最新动态,看看哪些东西自己是可以做的。后面我主要是为 Kitex 服务发现、服务注册相关的组件、单元测试等方面做了一些贡献。

个人关于云原生和开源文化的认识

那么我是怎么一步一步了解或者接触到开源文化的呢?
这大概要回顾 2018-2019 年,当时在深圳经常参加一些技术峰会、Meetup 等活动,这个城市的技术氛围还是比较不错的。那时就能明显地感觉出来云原生、围绕容器的虚拟化 K8S 相关一定是一个技术趋势,当时也是因为对 Docker 感兴趣,所以更多地留意了 K8S 这些相关的技术领域。
最后在机缘巧合下,了解到 Linux Foundation,即 Linux 开源基金会,会有一些技术认证。当时我想通过这种机会,特意地学一些特定的技术,比如他们推出了 CKA 、CKS,所以这也是一种学习的渠道。
不仅如此,我还会经常关注基金会推出的一些开源项目。当时在学 K8S 的时候浏览了一遍 K8S 相关文档,给他们的文档提过一些 PR ,这是我最早接触到开源。

为什么要参与开源以及我理解的开源精神

  • 学习优秀的开源项目
避免做井底之蛙,要走出去看看别人是怎么做的。比如:优秀的编码、代码规范、设计模式、架构思路等等,寻找更多正例和最佳实践,开阔技术视野。
  • 开源世界是一个包容开放的世界
你可以在 Github 发现世界上更多更优秀的人,与他们共事,向他们学习。了解他们的技术思路、思维方式、职业规划,也会给自己带来启发。
  • 协同共建,从点滴做起,融入社区带来成就感
开源很多时候是用爱发电,开源的第一步是把代码开放出来,后边很多时候是靠社区驱动迭代和演进,众人拾柴火焰高是开源的精髓和意义。我们为社区贡献的点点滴滴以后都有可能帮助很多用户解决问题,这是开源项目生命力的体现,也是我们成就感的来源。

个人以后对开源的想法

如果可以,我以后想把开源当成事业。主要原因有以下几点:
  • 梦想
曾经有一个梦想,能够远程工作,即为开源产品贡献代码或者在一个基金会工作。
  • 布道者
可以和喜欢的人和事打交道,不用考虑太多商业化,不用内卷。
  • 未来计划
当前想法可能不能一蹴而就,但是至少在 CloudWeGo 找到了一个切入点,希望能更好地为社区贡献一份力量。从字节跳动的一系列动态和战略布局来看,CloudWeGo 未来一定可以在 Go 微服务领域做出更多具有影响力的开源项目。
最后,分享一名开源爱好者,我觉得他是很有代表性、具有极客范儿的一个人。他叫苏业钦,是云南的一名儿科医生,但是他业余其实也是一个 Linux 玩家,大家感兴趣可以了解一下。
最后希望大家都能够在代码的世界里找到乐趣!

分享人:杨文


关于这个问题,从我的实际经验出发,将从两个方面进行分享:
  1. 自己去做的角度;
  1. 参与项目的角度。

自己去做的角度

自己主导去做开源,其实相对来说不是很硬核,比如 Go 夜读这样一个 Repo。
Go 夜读目前在 Github 上 Star 数应该有 1W+,其实 Star 数量本身不会代表什么,它更多代表的是一种经历,从这个角度来看,我觉得 Star 数的参考有助于我们理解开源的精神,或者说它是开源所带来的反馈。
  • 明确开源项目运作的意义
不管是本身很硬核的项目还是基础组件,或者是一些能解决实际问题的、帮助大家学习成长的内容,我们都要去想这个东西究竟有没有帮助,怎么样做起来,这其实就是思考参与开源的一个模式。如果你是为了赚取 Star 数,那可能会有违你的初衷。其实在我看来你要把它当做一个开源项目去运作,这个里面能够学到的东西或者能够去理解开源精神,以及开源所带来的一些正反馈其实还是蛮多的,不需要关注 Star 数本身。
  • 项目发展需要过程
  1. 起初,开源项目的发展可能是由某一两个人发起的。在这个过程中,你可以引入一些对这方面感兴趣的人,或者通过你的项目给别人带来帮助,然后吸引别人进来,进而逐步扩展项目规模。不管是什么样的项目,其实都是这样的过程。即便是那些现阶段比较成熟、规模较大的项目,比如说 Go 夜读、 PingCAP 的 TiDB 以及其他的一些 Go 的 Repo ,其实都是这样一点一点做起来的。
首先就是要去做,做到一个你认为还不错的程度,然后在你的朋友圈或社区去推广。比如 CloudWeGo,其实也是通过实际解决了一些场景需求的问题,然后开源出来,之后一步一步稳扎稳打发展起来。类似今天我们这样的一个活动,其实都是在实实在在地帮助社区的人。项目本身如果有价值且有活力,不管你是组长还是参与者,只要加入其中,其实都能学到很多东西。
以上就是从自己的角度出发,找到一个你自己想要去投入的项目,或者对于你来说需要解决的痛点问题,然后持续迭代。是金子总会发光的,项目也一样,只要项目是实实在在有价值的,总会被更多的人关注到。

参与项目的角度

另外一个视角就是参与一些项目,但在参与项目前要有所选择,选择标准可以参考以下三个方面:
  • 能解决你的问题。这是评判你要怎么选择项目、参与项目的条件或标准。
  • 确定开发语言。选择相对来说覆盖面比较广的开发语言,不管是项目构建还是开源的运作会更体系化、规范化,避免踩坑。
  • 参与开源项目的目的。考虑开源项目的影响力,能否有所学习和收获并为项目输出一些自己的价值。
就我的经验而言,建议选择较为完善、影响力比较大的开源项目。在 2018 年我参与 TiDB 并获得了 Active Contributor,虽然我参与实际硬编码的维度不是很深入,但是更多的是重在参与。很多东西必须得投入去做,才能持续产生和输出你的价值,同时也不断吸收到社区给你的反馈。
总之,选择当前适合你的,以及明确你想要成为什么样的人,承担什么样的角色,然后对应地寻找一些项目帮助你完成目标。其实参与开源项目也要量力而行,选择真正适合自己、感兴趣的领域,然后在这个技术领域之上继续深耕。只有通过长期的技术方面的投入,才能够在该领域里面真正有一些比较好的产出和结果,从而真正学到内核并获得提升。

分享人:李龙


关于开发者如何参与开源的问题,我提供了以下三种参考方式:
  1. 通过参与 First Good Issue 贡献 / 解决社区 Issue;
  1. 通过实战(项目实战 / 性能对比等),发现可优化的点,解决并反馈社区;
  1. 直接阅读源码。

参与 First Good Issue 贡献 / 解决社区 Issue

  • 一般社区会有很多积压的 Issue ,初期可以挑选一些简单的 Issue。
我最初做开源也是因为写业务,基本上在字节内部所有的 Go 服务都会使用 Gorm 作为它的 ORM 。我在了解 Gorm 的时候,发现当时 Gorm 的 Issue 其实是比较多的,包括现在也是积压了 100 多个左右。于是我发现可以通过解决一些社区的 Issue 上手参与开源。
有的 Issue 可能是使用方面的 Bug,可以尝试修复这些 Bug。我通过不断地解决 Issue ,逐步熟悉框架,有简单的 Bug 去修复,大概持续一到两个月,对这个框架基本上也就比较熟悉了。
  • 开源社区一般会不时提供新手任务,大家可以积极参与。
CloudWeGo 社区经常发一些 First Good Issue,即新手任务,可以通过接新手任务参与社区。我和伟超老师起初接的新手任务都是服务注册发现的扩展、一些 Demo 服务、示例服务等,在写这些示例服务的时候,其实也可以发现一些问题,然后再去修复。
综上,可以通过社区发 Issue 或者自己主动找 Issue 的方式参与开源。相比而言,像 Gorm 本身 Issue 就很多,感兴趣的同学可以挑一些简单的 Issue 参加。CloudWeGo 会定时发一些新手任务,大家也可以积极参加。

实战(项目实战 / 性能对比等)

  • 修改文档上的实例 Demo 反馈社区。
一些开发者可能会看文档上的 Demo,把 Demo 粘贴过来运行,但是发现直接粘贴过来无法运行,或者是文档写得有问题,此时可以通过修改文档上的实例 Demo 反馈社区参与开源。
  • 做一些压测,去压下不同框架的性能。
之前就有一些同学喜欢压测对比不同框架的性能,这种方式需要尽量保证公平、清晰的原则,事先对框架有所了解,通过压测后发现可以优化、迭代的点,从而优化后贡献社区。

直接阅读源码

当然也可以直接阅读源码,但是对于小白来说比较难上手,也会比较痛苦。
以上是三种参与开源的方式,另外在对象选择上我个人比较倾向于研究平时会使用到的项目,比如我平时会使用到 Kitex 或 Gorm ,这样感受会好一些。

议题二


CloudWeGo 开源项目主要方向是云原生微服务框架, 这类项目主要的使用场景是什么样的?学习这类项目的价值点在哪里?混迹社区有什么经验分享?

分享人:李龙


CloudWeGo 的使用场景

如果是希望选择一款高性能、灵活性强以及可以满足内部定制化需求框架的用户,CloudWeGo 提供的微服务框架会是一个不错的选择。CloudWeGo 开源项目主要有以下特征:
  • 高性能( Netpoll / Sonic / Frugal 等)
比如底层的 Netpoll 本身就是一个高性能的网络库;Hertz 内置了 Sonic 高性能的 JSON 编解码库。
  • 提供了丰富的扩展能力
无论是 Kitex 还是 Hertz 都提供了丰富的扩展能力。Kitex 比如说像限流扩展、Transport Pipeline-Bound 扩展等;Hertz 本身的扩展能力也比较强,可以满足一些比较个性的定制化需求。
  • 优化的用户 API 接口
提供了一些比较友好的用户 API 接口,并没有特别复杂。

学习这类项目的价值点

  • 学习框架分层设计 / 一些比较好的设计点
【举例】Hertz 的四层分层设计,各层之间不耦合,扩展性强。
  • 学习框架的一些性能优化的 tip ,扩展自己的视野
【举例】Netpoll 的性能为什么会比标准库在某些上场景下高很多?
参考资料:https://juejin.cn/video/7046282096435789835
  • 压测框架性能,探讨交流学习
社区里很多同学喜欢压测框架,尤其是针对 Kitex 和 Hertz,以及它的两个 Benchmark 仓库。我们非常希望能在社区见到这些关于底层的技术优化以及相关讨论,并且不拘于 Kitex 和 Hertz 两个框架之间的差异点及使用方式。通过对类似于像 Hertz、Fasthttp、Gin 框架的性能测试和对比,可以关注其性能改进以及性能优化这种比较底层的技术深度的逻辑。

社区经验分享

  • 一个不好的 Case:对使用的框架提出了一些模糊的问题 / 评价。
    • 【举例】经典评论:“设计的不太好 / 设计的太重了”,具体哪里设计的不好 / 太重了需要说出理由,这种 Case 请及时规避,尽量用数据说话。

议题三


程序员作为项目使用者的角色,开发者作为开源项目设计者的角色, 这两种角色关注的点有什么不同?作为一个经历过这类角色转换的社区 Committer 来说,有什么经验可以分享?

分享人:王伟超


项目使用者视角

作为一名项目使用者,在考量开源项目时会考虑以下几点:
  • 开源项目是否会持续维护;
  • 文档是否丰富;
  • 社区是否活跃;
  • 当前项目是否可用、好用,能解决当下团队的技术问题;
  • 不满足的地方是否能扩展。

开源项目设计者视角

作为一名开源项目设计者,主要是考虑如何更好地或者更快地帮助用户解决其问题。以 CloudWeGo 项目来说,作为字节内部实践的总结,开源出来是想帮助更多人解决一些共性问题,因此可能会更多考虑以下问题:
  • 通过维护项目接受用户反馈,还有哪些共性的问题没有覆盖到;
  • 开发新的一些特性;
  • Bug 的维护是否及时;
  • 能否比较快的帮助用户解决他们遇到的问题;
  • 文档维护与不断丰富,业务案例的整理。

议题四


在社区视角和全局角度下, 谈一谈为什么大厂都在招聘 Go 工程师?程序员应该如何规划自己的职业发展?程序员最终的归宿是哪里?

分享人:杨文


为什么大厂都在招 Go 工程师?

  • Go 语言的逐步发展
我觉得 Go 发展起来很重要的原因,在于云原生方向的发展、Docker 容器化领域、 K8S 包括后面串联起来的 Grpc 整个生态,从而导致或者触发了一些基础组件的研发。再加上云原生、K8S 在各个厂商的应用,触发大家去做很多的基建、流控、分布式链路追踪业务,以及后续很多基础组件的开源都选择了 Go 语言。
  • Go 语言的特性
基于 Go 本身的语言特性,去做这些事情是比较擅长的。Go 语言本身高性能且简单的特点,具有切换成本低,上手门槛低的特征。语言基础方面,C 语言基本可以实现无缝衔接,如果是脚本语言,可能相对要换一下思路,但是 go 的性能比较好,PHP 转 Go 可以解决很大的一个性能问题。而且 Go 上手很快,官方文档运行 demo 也很快,所以如果要去学习不用担心会很难以上手。
  • 大厂的应用场景
大厂其实会有实际的一个应用场景和解决问题的需求。Go 语言可以很快上手并完成相关业务,速度快、性能好也满足了其业务需要。从基建的维度看,之前大厂很多时候可能用 C、C++ 或者 JAVA 构建整个链路,一套下来会比较影响效率,相比较而言,Go 的实现就会比较快速、高效。

程序员的职业发展及最终归宿?

我有一个观点:语言只是用于解决问题的工具。
关于个人职业发展和职业道路,需要考虑好以下几点问题:
  • 本身擅长语言,希望在技术深度上去发力?
  • 结合所在业务,希望提升业务能力、相关的个人软性素质以及管理能力?
  • 通过技术解决业务的问题,带来业务价值?
从个人角度出发,如果要去看职业发展,可能就不能单单只是看你的技术栈或者你的技术点,而是要看你擅长的东西,以及在你可预见的时间段,你的优势和你想要发展的方向,跟当前工作结合起来,明确自己的需求。
Go 所带来的价值维度,只是作为一个能帮助你踏入门槛、或者能够帮助你去解决问题的语言工具。而个人的职业发展主要取决于当前你自身的定位和价值点。Go 是用于业务,还是去做基础设施和底层一点的内容,都取决于你自身所在的领域、或者是工作需求,它只是作为能够满足你职业发展需要的一门语言工具。
另外,当前我理解,go 工程师的工作还是偏向业务的,或者产品功能偏多一些,在基建或偏底层一点的相对比较少。大厂应该也是业务或产品居多,但是基建等其他方面的需求可能会逐步处于上升的状态。
Aftership Go 应用主要还是业务侧,还有一部分会和云原生或基础设施有一定的关系,但是还没有覆盖很广、或者像字节这种有专门的架构部门去做 Go 生态的基础建设。目前还没有,根据公司发展的阶段后面可能还是会需要并去展开做这方面内容。

议题五


大佬分享环节,大佬们关注的博主/学技术的网站/书籍推荐。

分享人:李龙


推荐原因:
  • 《设计数据密集性应用》
是一本特别经典的书,会覆盖到开发过程中各个方面遇到的一些问题,相对比较全面。
  • 《程序员的自我修养:链接、装载与库》
内容会比较偏底层相关,主要包括链接、装载、编译等。
  • 《Google SRE 工作手册》
不只是 SRE 需要看,研发也可以看。
  • 《微服务架构设计模式》
大家在做微服务开发时遇到的一些问题,在这里面会得到一些解决方案,供大家参考。

分享人:杨文


推荐原因:
  • 《微习惯》
比较偏向个人,从养成微习惯的心智与个人思考的维度展开。微习惯的理念,就是设想到一个非常小的维度,不管怎么样你都能达成,也没有负担。书中想表达的概念,就是很多时候做事情主要是要行动。习惯为什么难以养成?主要是在于你会认为它是一个负担、影响你的正常工作与生活、打乱你的节奏,所以你做不到。因此就要从很小的出发点开始。用一段时间,用一个微小的行动,约束自己逐步形成习惯,最终实现梦想或者达成目标。
  • 《沸腾新十年》
这本书推荐的原因是有很多小伙伴刚刚毕业,虽然知道移动端互联网,但是可能有很多东西还不是很了解,或者不太知道互联网发展的十年(2010-2020年)历程。在最近十年以内,有一些什么样的企业或者应用?有哪一些移动应用以及它们是怎么一步步发展的?这个过程中遇到了什么问题与变化?这本书会比较详细的展开讲解。
  • 《Salesforce 传奇》
这本书跟我现在所在的行业 ToB SaaS 相关。Salesforce 是 sale SaaS 行业的引领者,或者说是一个开创者。这本书就是介绍 Salesforce 从开始、到它逐步发展壮大的整个历程,是 Salesforce 的一部成长史。这本书对于 SaaS 行业有很大的指导作用,怎么样一步一步到哪个阶段、可以采用什么样的方式、或者会经历一个什么样的阶段,对于在这个行业里面去理解 SaaS 应该还是会有很多帮助的。

分享人:王伟超


  • 书单
我的书单推荐其实更偏向于“道”的层面,“道”的意思指这些书很多都是一些架构或者编码、编程的思维。Ruby 之父松本行弘的《代码的未来》里面有一点关于面向对象的解释令我印象比较深刻,书中解释了我们现在的编码编程为什么要从面向过程做到面向对象,它的好处是什么?背景是什么?大家感兴趣的话可以看一看。
  • 博客
面向信仰编程、极客兔兔,这两个是比较典型的博客。一个是面向 Go 设计底层的,一个是面向 Go 编码的一些框架、中间件的实现。Go 夜读这个是比较综合的,如果想在 Go 的技术栈深耕的同学可以了解一下。
  • 软技能
这其实是一个很大的话题。就职场软技能而言,比如敏捷开发,现在很多公司都在提议,我们作为开发也可以了解一下标准的或者说最佳实践,敏捷开发应该是怎么做的。还有就是沟通反馈,件件有着落,事事有回响,这些沟通的技巧也是需要大家注意的。

Q&A

Q:Go 语言后续的一些整体架构的演进如何?主要是为了支持什么?
A:主要是针对性能的问题,支持一些业务发展。就字节跳动内部的一些场景来说,框架调优主要是为了性能优化。比如对于框架而言,传输的整体损耗在数量大规模积累的基础上都是实打实的成本,所以通过优化性能可以减少我们成本的一些损耗。也正因为如此,字节跳动,包括 CloudWeGo,都在性能领域持续的推进,以期达到最优的状态。同时,希望更多关注这一方面技术,希望在这里能够获得一些极致的性能的框架,包括一些极致的性能的体验的同学持续地关注我们的项目。
 
Q:大厂对 Go 工程师的需求和要求?
A:大厂招聘 Go 工程师当前业务侧会多一些。还有一部分就是在做基础架构的内容,主要针对基础的框架,对其性能方面进行整体调优。这一部分所涉及到的语言会比较偏硬核,可能不光要会用 Go 而且关于 Go 的内核,包括语言生态、底层逻辑都要非常熟悉,然后再在这里面去做相关的一些框架的性能优化。
结合云原生现状,当前其在行业里处于发展中的状态,很多企业正在处于云转型的阶段,而这个过程是需要一定时间的,可能无法一次性迁移到位。这种状态之下,其实会涉及到非常多的后台逻辑与操作,所以针对架构调整、演进可能也会是后续 Go 工程师发展的一个职业方向。而根据不同公司发展的阶段,后续更多的公司发展起来之后,可能会增加对于基础建设的需求,推进和维护自己的基础架构,由此关于 Go 语言工程师的需求也会有一些相应的提升。

更多资讯

展开阅读全文
加载中

作者的其它热门文章

打赏
1
2 收藏
分享
打赏
0 评论
2 收藏
1
分享
返回顶部
顶部