关于后端:学习开源项目的几个实用套路

2次阅读

共计 3280 个字符,预计需要花费 9 分钟才能阅读完成。

记得我的 leader 之前说过,很多人工作之后就丢失了钻研技术的激情,这个的确,我发现自己多少也有这个问题。

转瞬曾经毕业一年多了,回忆这一年,有些羞愧,感觉不仅技术能力上并没有什么特地值得一提的提高,而且在其余各个方面都感觉本人有待进步。

和身边一些敌人交换之后,他们大多示意有同感,感觉工作后就没有能源学习提高了。置信我的读者里也会有相似的问题,所以本文就如何在工作后持续晋升技术能力这个问题,分享给大家我的一些反思和解决方案。

我仔细分析了本人懈怠的起因,次要有以下两个方面:

1、学习是由需要驱动的

带着需要 / 问题去学习其实是最高效的,但大部分工作中用到的技能其实比拟根本,俗称 CRUD。那么习惯性的思维就是赶快做完了事,能跑起来就行了,所以在工作之后的确就比拟难有继续的自驱力去学习新技术。

之前我和一个敌人聊到这个问题,他说多给本人打鸡血,多换工作就好了。毕竟俗话说得好,面试造火箭,工作拧螺丝,多造造火箭,能力不就下来了?

我感觉他在调侃,能力晋升必定不是靠三分钟热度突击进去的,而是须要在日常工作中进行继续的积淀和积攒。每次面试前背八股文只能算百米冲刺,而整个职业生涯就好比是一场马拉松,须要一种可能继续稳固输入的策略。

从这个角度看,必定不能光指望着从公司业务中学习,没有需要咱就得发明需要。比方我会尝试从两方面动手:

首先,我会联合本人已有的积攒尝试做些有价值的货色进去,比方之前就联合我的公众号开发了各种插件不便大家学习,顺带就学习了各种插件的开发,技多不压身嘛。

另外,我会保持看一些技术书籍,关注一些新兴技术的倒退。但说实话,我看完过一段时间就没什么印象了,这也就引出了第二个问题。

2、学习是须要在反馈中强化了解

具体来说,必须要有一套机制,让我用学到的货色解决理论问题,最好能和同行交换碰撞,失去反馈而后迭代降级,能力算无效的学习。

就好比高考,单纯背书是没有用的,须要一直刷题、考试,强制咱们使用常识,并通过分数给予反馈。刷算法题也相似,你能够看我的历史文章学习技巧,但必须去刷题平台上亲自实操并取得反馈,能力真的把握这些技巧。

那么为什么我看了书就忘呢?就和很多读者说刷完算法题就忘是一个情理,我学习技术书籍也只是看一遍,并没有深度体验这些技术,没有在工作中应用到这些技术,也没有参加到这些技术的倒退中去,所以只能算是浅尝辄止,不能算真正无效的学习。

置信上述问题很多读者也会遇到,我尝试过很多办法,明天分享一个老本比拟低的计划: 参加开源,尤其是新兴的开源我的项目

首先,下面说到的两个问题在开源社区中都失去了解决:

1、成熟开源我的项目的 issue 列表里有很多用户反馈的 bug 和新想法,这其实就是需要。咱们齐全能够带着需要去尝试解决问题,亲自参加到开源我的项目的建设中来,深刻理解和学习这个我的项目。

2、成熟的开源我的项目会被很多大公司采纳,这些公司在应用过程中遇到的简单问题都会反馈到社区,社区会进行探讨并解决,咱们齐全能够参加到这个过程中,学习业内前沿的解决方案。

PS:须要阐明的是,我的算法仓库 fucking-algorithm 尽管取得了很多 star,但严格来说只能算我的集体作品,不能算开源我的项目。一般来说,有很多大公司应用的代码仓库能力算真正意义上的开源我的项目(比如说 Apache 基金会旗下的顶级我的项目)。

另外,成熟的开源我的项目都会有一套标准的开发流程,每段代码都能够追溯到对应的问题及探讨过程,可能让咱们在浏览源码时理解足够的背景信息,不像公司的外部零碎,文档只能靠口口相传。

所以,只有用心去看,开源我的项目从学习到上手开发并不会遇到什么坑,学习曲线也不会很平缓,很适宜集体学习钻研。

当然,最重要的是,沉闷参加开源建设是展现本人能力的无力证实

这一点须要着重讲一讲,因为我感觉国内对开源社区的了解还是比拟匮乏的,就连我本人以前对开源社区都没有什么概念,浮浅地认为把一堆代码丢在 GitHub 上就算参加开源了。

实际上,参加开源建设和在公司写代码是相似的,也须要你深度参加到某个开源我的项目中去,积极参与探讨并给仓库提交代码。当然,开源社区会给予你一些头衔,比方 Apache 基金会旗下的开源我的项目有一套比拟成熟的治理计划:

向仓库提交过代码的叫 contributor;如果你继续提交代码,能够成为我的项目的 committer,给你调配一个 @apache.org 邮箱,并领有诸如合并 PR 之类的一些仓库权限;再进一步能够成为 PMC,领有对我的项目提案的投票权。

这些头衔都是公开可查的,那么如果你对开源我的项目继续奉献成为 committer 或者 PMC,写在简历上当然是个很大的加分项。

这个情理很好了解,你在公司里做的货色再牛逼,人家没法查证也就不肯定信,但在开源我的项目里写的代码、取得的荣誉都是公开的,那当然能够作为技术能力的无力证实

不过话说回来,权力越大责任越大,取得开源社区的这些头衔的同时,也意味着你须要在我的项目上继续破费精力,和社区一起把我的项目做大做强。

那为什么最好参加新兴的开源我的项目呢?也很简略,新兴的开源我的项目必定会存在问题,这样的话才有机会轮到咱们去解决问题嘛。

如何参加开源

我最近在钻研学习 Apache Pulsar 这款新兴的云原生音讯队列,之前我也发了几篇文章:Apache Pulsar 的设计、存储系统中的 LSM 树、用音讯队列制作一款联机小游戏,这里我就以参加 Pulsar 社区为例分享一点教训。

我感觉首先须要明确的一点是:不要不敢动开源我的项目的代码,它也是可能出错的,找到谬误你也能够提 PR 来修复

以前我对开源我的项目还是有些心怀敬畏,尤其再加个 Apache 顶级我的项目的 title,让我感觉这我的项目不得了,外面的每一行代码都很柔美神圣,不能乱动。

其实并没有这么夸大,代码嘛,必定是人为了解决问题而编写的,会有柔美的代码,也会有屎一样的代码和各种 bug。

所以不必管什么 title,开源我的项目实质上和公司或者实验室外部开发的零碎并无区别,只是开源我的项目参加的人多、性能比较复杂全面、代码量大、打的补丁多,还要思考向前和向后兼容。种种原因叠加在一起,导致它看起来简单宏大,须要咱们急躁花工夫理顺。

第二个倡议是:不要上来就看代码,先尽可能多地应用

当然,其实大型项目的开发也遵循一些固定模式套路,有些大佬兴许能间接读源码,不过对于大多数人来说是不倡议这样做的。

为什么呢?因为间接硬看代码是最低效的形式,最快的学习形式是带着问题学习,而问题只能从你应用的过程中来,所以要先应用。

比方说,如果你负责公司的音讯队列技术选型,那么能够对 Pulsar 进行调研,并参加到社区中来。这是一个多赢的事件:对公司来说,抉择 Pulsar 这样一个云原生音讯队列是面向未来的抉择;对社区来说,公司应用场景中遇到的问题和需要能反哺我的项目的倒退;对集体来说,也是参加开源社区的绝佳切入点。

如果你是集体学习,那么先认真浏览官网的文档,搭建一个 Pulsar 集群先跑起来,试用一下基本功能。而后能够尝试用 Pulsar 制作一些有意思的货色,比方一个聊天零碎等等,做这些小利用是 Just for fun,同时有助于咱们摸索 Pulsar 的性能并可能在应用中找到问题。

比方我在前文 用 Pulsar 做一个联机小游戏 借助音讯队列实现了多个玩家之间事件的同步,其实能够玩的性能还有很多,比方利用 Pulsar Function 的流解决性能做一些分数统计之类的事件,我筹备有空的时候再更新欠缺一下。

把各种性能玩明确之后,必定也要花费一些工夫去浏览源码,这是最难的一步,但也是难得的晋升本人技术能力的机会。对于源码的浏览其实也是有套路的,我后续筹备专门开一个专题来讲,大家期待就好。

以上就是我的一些思考和尝试,大家有趣味的话无妨也多在 GitHub 上逛一逛,找一个感兴趣的我的项目参加进去。如果你想和我一起钻研 Apache Pulsar,能够去仓库看看:

https://github.com/apache/pulsar

更多高质量干货文章,请关注我的微信公众号:labuladong

正文完
 0