如何参与一个顶级开源项目

前言

最近我的事情比较多（搬家、换工做、短暂休息）因此一直也没有顾得上博客更新，刚好最近收到一封邮件提醒了我。

也是时候写一篇文章来聊聊参与开源项目的事（最近也确实进入了笔荒期）。

ps:第一次收到这样的中秋节礼物，加上 Dubbo 社区的活跃及阿里的重视度，还在作 PRC 或微服务技术选型的朋友能够考虑 Dubbo。

参与开源

如今具体来聊聊参与开源的事；

平常几乎全部的开发者都会享受到开源项目所带来的便利甚至是收益，受限于环境早在十几年前甚至几年前开源活动一直都是有国外开发者主导。

但这几年国内互联网公司逐渐国际化扩大影响力也很大程度的提升了咱们的开发水平，以 BAT 为首出现了许多优秀的开源项目。

如今甚至参与开源项目还能另辟蹊径的拿到大厂 offer，因此其实很多朋友都想参与其中，可能这事给人的第一感受就不太容易，因此如今还卡在第一步。

具体步骤

如下是以我我的经验总结的几大步骤：

• 发现问题或自荐 feature 。
• fork 源码。
• 本地开发、自测。
• 发起 pull request 。
• 等待社区 Code Review 。
• 跟进社区意见调整代码。
• 审核经过，合并进 master 分支，完成本次贡献。

下面我会结合最近一次参与 Dubbo 的流程来具体聊聊。

发现问题或自荐 feature

首先第一步天然要搞清楚本身本次贡献的内容是什么？一般都是解决某个问题或者是提交一个新的 feature ；前者相对起来更加容易一些。

固然这个问题能够是本身使用过程当中发现的，也能够是 Issues 列表中待解决的问题。

以本次为例，就是我在使用过程当中所发现的问题，也提交了相关 Issue 并写了一篇文章记录并解决了该问题：What？一个 Dubbo 服务启动要两个小时！

值得注意的是在提交 Issue 以前最好是先在 Issue 列表中经过关键字检索下是否已经有相关问题，避免重复。

同时提交以后也许社区会进行跟进，被打上 invalid 标签认为不是问题，或者是使用姿式不对也是有可能的。

fork 源码，本地开发

当肯定这是一个待修复的问题时就能够着手开发了。

首先第一步天然是将源码拷贝一份到本身仓库中。

接着只须要 clone 本身仓库中的源码到本地进行开发。

先回顾下我遇到的这个问题。

简单来讲就是启动 Dubbo 服务很是缓慢，通过定位是 main 线程阻塞在了获取本机 ip 处。

因此当时我提出的方案是：在获取本机 ip 时加上超时时间，一旦超时便抛出异常或者是再次重试，但起码得有日志方便用户定位问题。

问题是主线程会一直阻塞在此处 InetAddress.getLocalHost().getHostAddress()，但又须要知道它阻塞了多久才好判断是否超时。

因此只能再额外开启一个线程，定时去检测 main 线程是否已经完成任务了，如下即是我第一次 pr 的内容。

此次的重点不是讨论这里具体的技术细节，因此简单说下步骤：

• 额为声明了大小为 1 的线程池。
• 再声明了一个 volatile 标志用于判断主线程是否有完成任务。
• 声明了一个 condition 用于新线程作等待。
• 最后只须要运行这个线程用于判断这个标志便可。

如何自测

开发完成后下一步就是自测，因为这类项目是做为一个基础包依赖于其余的项目才能运行的，因此一般咱们还得新建一个项目来配合作全流程测试（单测除外）。

这里我以为仍是有几个小技巧值得注意。

第一个是版本号；由于在本地测试，因此须要使用 mvn clean install 将包安装到本地才能在其余项目中依赖进去进行测试。

但因为咱们从官方拉出来的代码版本都已经发布到了 maven 中央仓库中（不论是 release 仍是 snapshot），因此咱们本地仓库中确定已经存在这几个版本的 jar 包。

一旦咱们执行 mvn clean install 将本身修改的代码安装到本地时，大几率是会出问题的（也多是我姿式不对），这样就会致使新建的项目中依赖不了本身新增的代码。

因此我一般的作法是修改版本号，这个版本号是历来没有被官方发布到中央仓库中的，能够确保本身新增的代码会以一个全新版本安装到本地，这样咱们再依赖这个版本进行测试便可。

不过再提交时得注意不要把这个版本号提交上去了。

发起 pull request

自测完成后即可发起 pull request 了，不要大意，这里还得有一个地方须要注意，那就是代码换行符的问题。

一旦换行符与源仓库的不一致时，git 会认为此次修改是删除后重来的，这样会给 code review 带来巨大的麻烦。

就像这样，明明我改动的行数并很少，但 git 确认为你是推翻了重来，致使审核起来根本不知道你改了哪些地方。

最简单的方法就是设置本身 git 的全局配置，能够参考这里。

# 提交时转换为LF，检出时转换为CRLF
git config --global core.autocrlf true
 # 提交时转换为LF，检出时不转换
git config --global core.autocrlf input
 # 提交检出均不转换
git config --global core.autocrlf false
复制代码

确认没问题后即可点击这里发起 pull request，后面按照引导执行便可。

固然各个项目之间还会有本身定制的贡献流程，最好就是查看官方的贡献指南。

dubbo.apache.org/en-us/docs/…

Code Review

pr 发起后即可等待社区审核了。

在这过程当中要充分和社区进行交流，有可能你的方案和社区的想法并不一致。

好比像我此次：

最终经过沟通加上本身后面的思考以为仍是社区的方案更加轻便合理一些，达成一致以后社区便将此次 pr 合并进 master 中。

其实整个过程我以为最有意义的即是 code review 的过程，全部人均可以参与其中头脑风暴，其中也不乏技术大牛，不知不觉便能学到很多东西。

相似案例

虽然我以前的方案没有被采纳，但相似的用法（一个线程监控其余线程）仍是很多，正好在 Dubbo 中也有用到。

即是其中核心的服务调用，默认状况下对使用者来讲这看起来是一个同步调用，也就是说消费方会等待 PRC 执行完毕后才会执行后续逻辑。

但其实在底层这就是一个 TCP 网络包的发送过程，自己就是异步的。

只是 Dubbo 在你不知道的状况下作了异步转同步，这样看起来就像是一个同步方法。

如图中的红框部分，Dubbo 自身调用了 get() 方法用于同步获取服务提供者的返回结果。

逻辑其实也挺简单，和我上文的方案相似，只是这里的 isDone() 函数返回的是是否已经拿到了服务提供者的返回值而已。

总结

本次总结了参与开源的具体步骤，其实也挺简单；就如官方所说哪怕是提个 Issue，修改一个错别字都算是参与，因此不要想的太难。

最后还简单分析了 Dubbo 调用过程当中的异步转同步的过程，掌握这些操做对本身平时开发也是颇有帮助的。

你的点赞与分享是对我最大的支持