TAGS：                                                                                                                                                                              

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

首页 编程分享 EXPERIENCE 正文

CloudWeGo 转载 编程分享 2022-08-21 23:09:03

简介 圆桌议题 议题一：开源自 2020 年开始列入国家规划后，开源项目越来越多。开源项目的涌现，为大家提供了学习和深度了解升级项目的途径。...

圆桌议题

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

嘉宾

议题一

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

分享人：王伟超

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

如何与 Kitex、CloudWeGo 社区结缘

其实与 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 语言工程师的需求也会有一些相应的提升。

更多资讯

转载链接：https://my.oschina.net/u/4843764/blog/5567708


Tags：

333 0 0 0


本篇评论 —— 揽流光，涤眉霜，清露烈酒一口话苍茫。


    声明：参照站内规则，不文明言论将会删除，谢谢合作。


      最新评论




ABOUT ME

Blogger：袅袅牧童 | Arkin

Ido：PHP攻城狮

WeChat：nnmutong

Email：nnmutong@icloud.com

点击排行

最新评论

猜您喜欢

标签云

友情链接