开发者及团队能从LibreOffice那里学到什么?

作者:萧过无痕 分类: 建站资源 发布于:2013-2-23 23:58 ė224次浏览 60条评论

[CSDN编译/王然]在Oracle收回OpenOffice.org之后,LibreOffice不仅准时地发布了新版本,而且非常有序,令人印象深刻。LibreOffice的Michael Meeks在FOSDEM上做了一个演讲,阐明了他们究竟是如何管理这个庞大并且复杂的团队,以及处理庞大的LibreOffice代码库。InfoWorld对此进行了报道,CSDN编译如下:

“LibreOffice:清理并重构庞大的代码库”的演讲者——Michael Meeks——是Suse的开发者,自2000年以来一直工作于LibreOffice(在此之前是OpenOffice.org)。Meeks在演讲中提到了LibreOffice的开发挑战和LibreOffice 4.0版本的新功能,本文主要关于前者。另外,他们还开发了一套名为“bi-bisect”的技术,可能是一个伟大的大型、复杂代码库解决方案。

降低壁垒

LibrreOffice社区最初是如何形成的?OpenOffice.org的开发者形成了最初的核心,但让开发变得简单而且有趣是非常关键的一步调整,为此,项目降低了参与开发的障碍。邮件组不再是侧重于现有开发者,现在更多的是面向新人;此外,一个名为“easy hacks”的页面为新人提供了一个简介的入门,而且README文件也随处可见。

项目采用Git作为版本控制工具,使用最著名、最广泛使用的开源工具也让参与贡献变得简单。通过添加Gerrit这个Meeks称之为“免许可提交”的功能,代码贡献过程得到了进一步的简化。

LibreOffice的代码库极难建立,因此项目使用了自动持续集成构建服务器Tinderbox,这样开发者可以专注于编码工作,而无需为多个操作系统单独创建复杂的构建环境。项目中的德文也基本上被翻译成了英文,这样更便于得到世界范围的帮助(大部分开发者至少以英文为第二语言)。清理工作还包括大量地对旧方法进行现代化重构,并且清理了很多为已消失平台准备的代码——毕竟这是个已有20年历史的程序。

最近,该项目进行了更大规模、更有野心的重构,比如重新实现微软文档过滤器,并引入了基于布局的对话框(layout-based dialogs)来代替硬编码选项(hard-coded options)。Meeks还提到了很多进行中的重大改进,他的幻灯片(PDF)中提供了有详细的列举。

坚持质量

对于复杂、脆弱的遗留代码,任何改变都有可能导致破坏。事实上,回归( regression)是LibreOffice长期不变的目标。为了解决这个问题,项目采取了多个方法以保证在不破坏项目进程的情况下提高代码质量。开发人员大幅提高了单元测试的数目,来保证添加新功能的可能,因为越来越多的贡献来自新贡献者。

两种“文化”上的改进也影响深远。首先,面向bug追踪器Bugzilla的接口得到了显著改进,因此 终端用户可以更简便地报告详细的问题信息。Bugzilla Assistant是一个基于工作流的图形应用,可以引导用户穿过复杂的过程提交bug。第二,发布时间表已经被锁定在了一个可预见的范围,因此开发者知道他们应该何时启动(如果它满足质量阙值),也可以防止人们玩政治把戏、抬高个人的重要性。以上两个改进都加速了LibreOffice的开发进程。

但开发中仍然出现了破坏,有个来自Canonical绝顶聪明的成员Bjoern Michaelsen想出了一个简单的解决方案来允许QA团队的任何人去定位导致回归的bug:

Git有git bisect(平分)命令,可以帮助确定回归。开发人员通过调查某个出现问题的代码版本和未出现问题的历史版本比较来确定问题所在。Git会提供两者之间的commit,并询问是否出现了问题。通过多次bisect,很快就能隔离出引入缺陷的commit。

对Git的改进

非常不错的方法,但是LibreOffice是一个庞大、复杂的代码库,经常每天接收多达50+的commit;每次构建可能都需要数小时,因此上述测试法并不直接适用。

Michaelsen认为这可以通过存储Tinderboxes每次提交后产生的二进制文件来解决, 为此他专门建立了一个版本库,现在已经能够很容易地检测LibreOffice的完全构建版本,因此可以配合Git bisect测试。通过使用这种“二进制bisect”的测试方法(简称“bi-bisect”),一个甚至不知道如何构建代码的测试新人都可以检测出引入缺陷的commit,而且仅需bisect方法的1/4时间。

这些创新都会公布吗?Meeks展示了一个数据统计,证明正是如此。尽管存在复杂的重构,以及多样化并且充满了各等级开发者的社区结构,代码质量仍然在稳步提高,而且bug数量也保持在可控的范围内。

Meeks指出,传统企业为了保证质量,开发过程缓慢而且保守,因为传统的观点认为快速变化会降低产品质量。但他认为凡事总有两面性,TDF所使用的方法开放而且快速——即使代码的变化非常快速——低处理环境、快速构建方法,以及快速发布的时间线能够保证bug的快速修复。

这段经验中还有很多值得学习的地方,即使你的开发团队不愿拥抱这种急速开发模式,像bi-bisect、持续集成、简化bug报告以及无许可commit这样的技术同样值得学习、借鉴。

以人为本

最终要的一点开始时就是明确的,Meeks强调道: 开源项目听起来只是关于代码,但实际上更是关于人。

开发者和终端用户聚集在开源社区是因为他们有自己的兴趣和需求。为了成功,每个社区都必须关注于这些方面:社区风气、互惠互利而非利用、按许可构建 社区、友谊,以及最重要的——保持一切有趣。

LibreOffice之所以成功,不是因为它的代码,而是因为编写这些代码的人自我组织和对待他人的方式。信任每一个相关的人,并赋以足够的权利是每个开源社区都应该学习的地方。

原文链接:InfoWorld

本文出自 萧过无痕的栖息地 ,转载时请注明出处及相应链接。

版权所有:《萧过无痕的栖息地 》 => 《开发者及团队能从LibreOffice那里学到什么?
本文地址:http://www.54wuhen.com/post-3739.html
除非注明,文章均为 《萧过无痕的栖息地 》 原创,欢迎转载!转载请注明本文地址,谢谢。

发表评论

电子邮件地址不会被公开。必填项已用*标注

Ɣ回顶部