参加开源项目的一些经验和收获

现在算是正儿八经地参与到开源项目来了。一个多月的适应和学习,现在已经渐渐了解和习惯开源项目的开发模式。

在实验室写代码,是不用考虑太多的,写出的代码能用,能解决问题就好。这样做的原因很多,一是工期有限,二是知识不到位,三是没有支持,种种的限制让人很难写出满意的东西来。代码基本都是不能反馈给上游的。

而真正参加到项目中来,有明确的实现目标,一开始就做好设计——必须要反馈给上游,邮件列表的支持和讨论也很到位,所以做起事情虽然很累,反而还觉得舒服点。

过硬的代码能力是基本的要求,这个自不必多讲。但是编码没有想像中的那么重要,反而是一些设计上的取舍要花费大量的时间讨论。一段代码为什么要这样写不那样写,一个功能为什么要这样设计不那样设计,一个接口为什么要接受这个参数而不接受另外一个,这些讨论上花费的时间是很多的。最后编码的时间相对来说反而占的比例不是很高。一般来说key developer的见解都非常到位,他们可以指出代码和设计中的种种问题,还会考虑到兼容性、扩展性等等问题,和他们进行一番讨论会获益良多。不得不提的是,虽然key developer的意见比较重要,但是他们也不一定都是对的。作为开发者来说,大家完全是平等的,也不需要对他们完全盲从。

要引发高质量的讨论,首先要拿出来的就是patch。开源项目的geek们更喜欢用代码说话。连原型都没有就空谈,一般大家都不会理睬的。 Linus说过“Talk is cheap. Show me the code.”大抵就是这个意思。一个patch,可能要根据讨论的结果改好多次。幸运的话,大家表示没意见了,不想再拍砖了,就有机会进仓库了。这个时候应该最有成就感了。

所以总结一下,开源项目的发展就是靠大量的代码加上大量的讨论来推动的。当然,真正趟过这滩水和只看不做,感受还是有所不同的。

再来聊聊工具。

一是版本控制工具。这个是软件开发中的必备品了。现在开源项目越来越流行分布式的版本控制工具了,像Xen就提供了Mercurial和Git的仓库。分布式的好处不言而喻,大家都可以专心于自己的代码,不用受限于中心仓库。我个人比较偏好Git,用熟悉了基本的命令就不会有什么大问题,高级的用法可玩性也很强。

二是编辑器。这个是个人喜好的问题,搞*NIX的人,无非就是Emacs或者Vim。我个人喜欢Emacs,因为它的缩进控制更加智能,多 buffer支持也很方便;虽然一直被诟病体积大速度慢,但是这些问题在现在的机器上都不再是问题。Vim来写内核代码还是可以的,但是写Xen的代码有点难受。

三是邮件客户端。收发大量邮件的话,一个趁手的email client必不可少。Gmail的Web GUI用起来方便,但是不合适提交patch。现在我用Evolution和Mutt,其他的一些客户端可以看看Linux内核文档的email- clients.txt。

原文:Liuw

 

1 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部