记得我的 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
标签:学习,社区,项目,套路,代码,实用,开源,Pulsar From: https://www.cnblogs.com/labuladong/p/17024011.html更多高质量干货文章,请关注我的微信公众号:labuladong