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

前言

最近个人事情比较多(搬家、换工作、短暂休息)所以一直也没有顾得上TT快三计划更新,恰好最近收到一封邮件提醒了TT快三我 。

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

ps:第一次收到这样的中秋节礼物,加上 Dubbo 社区的活跃及阿里的重视度,还在做 RPC 或微TT快三服务 TT快三技术 选型的朋友可以考虑 Dubbo

参与开源

现在具体来聊聊参与开源的事;

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

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

现在甚至参与开源项目还能另辟蹊径的拿到大厂 offer,所以其实不少朋友都想参与其中,可能这事给人的第一感觉就不太容易,所以现在还卡在第一步。

具体步骤

以下是以TT快三我 个人经验总结的几大步骤:

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

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

发现问题或自荐 feature

首先第一步自然要搞清楚自己本次贡献的内容是什么?通常都是解决某个问题或者是提交一个新的 feature ;前者相对起来更加容易一些。

当然这个问题可以是自己使用过程中发现的,也可以是 Issues 列表中待解决的问题。

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

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

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

fork 源码,TT快三本地 开发

当确定这是一个待修复的问题时就可以着手开发了。

首先第一步自然是将源码拷贝一份到自己仓库中。

接着只需要 clone 自己仓库中的源码到TT快三本地 进行开发。

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

简单来说就是启动 Dubbo TT快三服务 非常缓慢,经过定位是 main 线程阻塞在了获取本机 ip 处。

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

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

所以只能再额外开启一个线程,定时去检测 main 线程是否已经完成任务了,以下便是TT快三我 第一次 pr 的内容。


这次的重点不是讨论这里具体的TT快三技术 细节,所以简单说下步骤:

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

如何自测

开发完成后下一步就是自测,由于这类项目是作为一个基础包依赖于其他的项目才能运行的,所以通常TT快三TT快三我 们 还得新建一个项目来配合做全流程测试(单测除外)。

这里TT快三我 觉得还是有几个小TT快三技巧 值得注意。

第一个是版本号;因为在TT快三本地 测试,所以需要使用 mvn clean install 将包安装到TT快三本地 才能在其他项目中依赖进去进行测试。

但由于TT快三TT快三我 们 从官方拉出来的代码版本都已经发布到了 maven 中央仓库中(不管是 release 还是 snapshot),所以TT快三TT快三我 们 TT快三本地 仓库中肯定已经存在这几个版本的 jar 包。

一旦TT快三TT快三我 们 执行 mvn clean install 将自己修改的代码安装到TT快三本地 时,大概率是会出问题的(也可能是TT快三我 姿势不对),这样就会导致新建的项目中依赖不了自己新增的代码。

所以TT快三我 通常的做法是修改版本号,这个版本号是从来没有被官方发布到中央仓库中的,可以确保自己新增的代码会以一个全新版本安装到TT快三本地 ,这样TT快三TT快三我 们 再依赖这个版本进行测试即可。

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

发起 pull request

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

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

就像这样,明明TT快三我 改动的行数并不多,但 git 确认为TT快三你 是推翻了重来,导致审核起来根本不知道TT快三你 改了哪些地方。

最简单的TT快三方法 就是设置自己 git 的全局配置,可以参考这里

# 提交时转换为LF,检出时转换为CRLF
git config --global core.autocrlf true

# 提交时转换为LF,检出时不转换
git config --global core.autocrlf input

# 提交检出均不转换
git config --global core.autocrlf false

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

当然各个项目之间还会有自己定制的贡献流程,最好就是查看官方的贡献指南。

http://dubbo.apache.org/en-us/docs/developers/contributor-guide/new-contributor-guide_dev.html

Code Review

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

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

比如像TT快三我 这次:



最终通过沟通加上自己后面的思考觉得还是社区的方案更加轻便合理一些,达成一致之后社区便将这次 pr 合并进 master 中。

其实整个过程TT快三我 觉得最有意义的便是 code review 的过程,所有人都可以参与其中头脑风暴,其中也不乏TT快三技术 大牛,不知不觉便能学到不少东西。

类似案例

虽然TT快三我 之前的方案没有被采纳,但类似的用法(一个线程监控其他线程)还是不少,正好在 Dubbo 中也有用到。

便是其中核心的TT快三服务 调用,默认情况下对使用者来说这看起来是一个同步调用,也就是说消费方会等待 RPC 执行完毕后才会执行后续逻辑。

但其实在底层这就是一个 TCP 网络包的发送过程,本身就是异步的

只是 Dubbo 在TT快三你 不知道的情况下做了异步转同步,这样看起来就像是一个同步TT快三方法 。

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

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

总结

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

最后还简单分析了 Dubbo 调用过程中的异步转同步的过程,掌握这些操作对自己平时开发也是很有TT快三帮助 的。

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

posted @ 2019-08-20 08:36 crossoverJie 阅读(...) 评论(...) 编辑 收藏