3

Blog: 遇见Dubbo

 2 years ago
source link: https://dubbo.apache.org/zh/blog/2019/01/26/%E9%81%87%E8%A7%81dubbo/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

RSS

遇见Dubbo

本文记录了一个小白成长为Dubbo committer的过程。
Saturday, January 26, 2019

我是一个有Dubbo情节的程序员。

Dubbo以不同方式,陪伴了我时间不长的整个代码生涯。不久前,通过社区投票,我被选举为Committer。当时我在朋友圈发了一句话,也是贯穿我从开始使用Dubbo、研究Dubbo、贡献Dubbo到最后成为Committer的全过程,一直为我提供内心无与伦比愉悦的源泉:成长这种事,能看见脚印特别幸福。

今天来个回忆杀,把我和Dubbo的那些事拿出来说说。

我知道Dubbo,是在我大三翘课出去实习的时候,那个时候是无知的,我眼里最牛的人就是能熟练使用各种配置,精通SSH框架的人。就是在那种情况下,我外出实习,遇到了一群影响我至今的人。当时也是机缘巧合,我们进行了两个非常小的模块的服务化改造。那时的团队除了我们老大,全是一群新兵蛋子,老大指哪我们打哪。老大说,就用Dubbo吧,从那时候开始,我才知道,哦!原来还有一种东西叫做RPC,还有个阿里巴巴的RPC框架叫Dubbo。

苦于当时非常有限的水平和高强度的工作,我和Dubbo的缘分也就停留在一面之缘的程度——要说认识谈不上,说不认识也牵强。

Contributor

我在二维火任职的一年算是我Dubbo生涯里承上启下的一年。二维火当时自己维护了一个Dubbo的分支,有一群对Dubbo非常了解的人。那时候,工作结束搞Dubbo,周六加班研究Dubbo。看源码,看不懂就debug一下,debug也不明白就问,问人,问google,里外折腾了个遍。

后来毕业加入网易云音乐。大概是今年五月份的时候,我发现了一个Dubbo的小bug,并且给Dubbo提交了pull request。在第一次被merge之后,非常受鼓舞,这才有了后续的故事。后来,回看这第一次提交,真的算是我和Dubbo的一个拐点,拐弯之后,我才逐渐走上一条成为Committer的路。

可能很多人看到这里要望而却步了,这也是做开源给很多人留下的固有的印象——是不是没发现BUG就不能提交pull request,不能做贡献?其实完全不是的,这里给大家敲黑板划重点:其实很多贡献者的第一次贡献,贡献的并非代码,而是文档修改或者单元测试。相比于BUG或者新的Feature,单测和文档上的修复门槛就比较低了。

我自己的方法论就是:先尝试增加单元测试,写单测的时候顺手debug+看代码。或者多看文档,了解框架的同时,发现错别字、语意不明或者文档上的链接干脆点不开的情况,直接提交PR到对应的仓库

万事开头难。第一次被merge代码,你就可以成为一个Contributor了。Contributor很多,但是Committer很少,下面继续说怎么从一个Contributor成长为独当一面的Committer

Committer

做开源和写代码一样,都不是一朝一夕的事情,而是量变促成质变的过程。这是一个没捷径可走的过程,欲带皇冠必承其重。身后的Dubbo功底自不必多说,这个部分主要是想跟大家说一下除了钻研和热爱之外,其他需要注意的地方。

首先是多提交高质量PR。任何一个PR都会被review,代码中的问题,思路上的偏差,都会被指正。提交PR是一个反复琢磨的过程。PR的质量不能简单的归结于新增了多少行代码,高质量的PR一定是经过缜密思考的,为什么删除代码,新增的代码有什么意义,修改之后有什么效果等等。希望大家更加重视质量而非数量,眼光放长远,相信你的收获一定会非常大!

第二个就是,我们需要培养一种思维方式——Apache Way。一句话概括就是社区重于代码。Apache是一个注重社区的的开源组织,其行为方式相比于目前我们的开发方式,还是有所不同,这里我举一个Apache Way的例子,用以说明传统方式相较于Apache Way的区别在哪里,这里假设我想为Dubbo开发一个功能A。

Old Way

  1. 功能设计:做一个设计文档(根据功能大小而定),大概划定需要修改或新增的类,大体设计接口等。
  2. 开发代码。
  3. 提交PR。
  4. Review & Merge

可以看到,我们整个过程中,真正与社区交互的只有最后一步。

Apache Way

  1. 功能设计:发送邮件至mailing list并且提交ISSUE,与社区成员共同探讨,产出一个设计文档(根据功能大小而定),大概划定需要修改或新增的类,大体设计接口等。然后再次发送邮件并且回复ISSUE,通知社区设计文档定稿或者方案确定。
  2. 开发代码:发送邮件至社区,通知社区成员我即将投入开发功能A,如需帮助,可以同时说明需要协助。
  3. 提交PR:发送邮件并且回复ISSUE,提醒社区开发结束,贴上PR地址以通知社区review代码。
  4. Review + Merge后,发送邮件并且关闭ISSUE,通知社区功能A的开发功能告一段落。

可以看到,Apache Way就是在整个开发过程中,不断地与社区交互,最大发挥社区的功能,汲取众人之力,这才是所谓社区以及所谓开源的含义。

Dubbo目前还在孵化阶段,整个Dubbo社区还不完善,我们也在跟着Dubbo一起成长,我们非常希望更多的Dubbo爱好者深度参与到Dubbo中,为你的代码生涯树一个里程碑。

相信过程,收获结果;天道酬勤,功不唐捐!


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK