学习开源项目的几个实用套路
记得我的 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
