● Free Software Engineering - 荔园在线 | 深圳大学学生论坛,荔园晨风BBS,深大在线网站

荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀

发信人: "非飞" <ffxz@gnuchina.org>, 信区: Linux
标题: Free Software Engineering
发信站: Bentium Ltd. (CN99) (Sun Dec 29 19:44:35 2002)
转信站: SZU!news.tiaozhan.com!news.neu.edu.cn!feed2.newsreader.com!newsreader.c
出处: 61.171.219.125

自由软件工程
version 0.1.1 ffxz(ffxz@gnuchina.org)版权所有，欢迎转载

0. 引子
软件工程，估计很多人都欣欣向往之，也许一想到那种大规模化的软件开发作业就心血
沸腾（不知道大家是否是这样的，至少当初我刚出校门就是这样的），所以自然就有一
个面向于Open Source的软件工程，最出名的当属《教堂与集
市》(http://263.aka.org.cn/Docs/c&b.html)那篇文章。
自由软件有很多种，小到一个源文件，几百行代码的开源项目，大到几百万行源代码级
的大项目。具体请参看方汉《Open Source 的开发模式探讨》文中的提法。本文中将
主要探讨小型Open Source、中型Open Source及“独裁”式的大型Open Source软件开
发，并完全从一个软件工程的角度来分析（主要是软件开发的组织及其他关系）。
在探讨他们之前，有必要先回顾一下传统的，面向商业化操作的软件开发过程。

1. RUP
RUP（Rational Unified Process）是一个套比较齐全的软件开发过程，几乎可以说无
所不包含。主要包含：商业建模，需求分析，分析与设计，实现（coding），测试，实
施等开发活动，额外附加有配置管理，变更管理，项目管理等，同时也支持开发过程跌
代。RUP总是试图从一个最全面的角度对待开发过程，让人觉得足够powerful！和RUP相
配套的则是UML（Unified Model Language），当然啦，UML也试图从一个最全面的角度
覆盖问题。

2.XP
XP（eXtreme Programming）是近几年来迅速崛起的软件开发过程，倍受大家的注目，
而且也基本上都是成功的案例，例如著名开源软件ACE+TAO都发表论文称，在自身的开
发过程中或多或少的采用了XP的做法。

XP强调软件开发中的四个值：简单、反馈、沟通、勇气。
简单：力求在软件开发过程中做到最简单：最简单的需求，最简单的设计，最简单的代
码……
沟通：客户与开发人员的沟通，开发人员与开发人员之间的沟通，开发人员与管理层的
沟通，哪一方出了问题都会对项目有所影响。
反馈：及时的反馈是迅速解决问题的可能，也是项目能够及时完成的可能。
勇气：开发人员的勇气是项目优质量完成的可能方案之一。

同时XP也提出了软件开发过程中的十二条实践准则：
Customer on-site，让客户加入到开发中来
每周40-hours工作制度
Metaphor，隐喻，简单的软件体系结构
Planning game，计划博弈，计划的跌代性
Code standards，一个项目中统一的代码规范
Simple Design，简单设计
Test Driven，测试驱动
Refactoring，代码重构
Pair Programming，结对编程
集体代码所有权
Continuous Integration，持续集成
Small Release，小型发布
XP详细信息可以参见：http://www.chinaxp.org/

在很多人眼里，软件工程是非常悲观的，或者说软件工程只是一些表面的东西，也认为
按照中国这种做法，也基本无软件工程可言。作者的一些看法：严格按照RUP，或者严
格的XP来说，国内的软件公司几乎没有几个可以做得到的。RUP、XP等等，或者传统的
软件工程都是纯理论的，纯理论的东西怎么可能和实际完全吻合？当然啦，按照这种模
式，在开源软件中也是彻底行不通的，如果谁想照搬，大概只有一种可能会是成功的：
封闭的商业式Open Source项目。

XP相比来说，按照Laszlo（还记得他吗？嵌入式软件开发方法Octopus II的革新者，
Fayfay 原创空间曾有过介绍）的观点：“XP基本上是RUP的一种简化，是杂乱无序软件
开发向上走的第一步。”

这就是核心所在，一个好的软件过程专家或者软件方法专家，最体现能力的一点：他是
否能够依据现存项目的情况，合理的对已有的过程或方法进行剪裁。而XP可以看成是对
RUP极度剪裁的结果。

所以说，其实无所谓悲观无悲观一说，也许现在国内企业软件开发的过程还达不到国际
上那种标准，但是这种杂乱无章仍然属于软件工程范畴，只要这种方式利于项目的开
展，项目能够完成，那么它仍然是软件工程。

3. Open Source项目
OK，现在已经演变成对现有软件过程的剪裁了，那么如何针对Open Source项目进行剪
裁呢？
XP的成功不是偶然的，必然有其合理的一面，不防先对XP来做一个剪裁，吸取其利于
Open Source项目开发的一面：
Customer on-site：在Open Source项目中，往往开发者就是使用者，就是客户。如果
不是，受条件限制也不太可能;-)
40-hours week：×
Metaphor：一个简单的软件体系结构，如果是多人协同开发，这个显然是必要的。
Planning game：一个跌代的计划，这个可以按照你规模的大小进行取舍。
Code standards：仅存在于多人协同开发情况。
Simple Design：无所谓用与不用，看自己吧。
Test Driven：比较好的一个方法。
Refactoring：优化自己的结构，不错的一个方法。
Pair Programming：基本上是一个不现实的方法，虽然有文章提及过网络Pair，但是效
果将大打扣则。
集体代码所有权：不错的一个方法，但是要建立在patch的基础上。
Continuous Integration：如果条件许可，可以试试，如果能够用，效果将比较明显。
Small Release:类似milestone的东西，优秀的方法。（正如同《大教堂与市集》一文
中说的）

4.自由软件开发方法
综合以上提及的以及从本人Open Source项目中经验来谈谈自由软件工程，或者说提出
一套行之有效的自由软件开发方法。类似XP，我也提出两个自由软件开发方法中的关键
值：兴趣、信心

兴趣是首要的，特别是当你想要去做一个Open Source的项目，或者希望别人能够加入
进来的时候。由于Open Source项目基本上是无商业利益可言的，能够驱动开发人员继
续下去基本上就是兴趣，否则只会出现那种，一个idea出来了，或者别人一个idea出来
了，只是去瞧瞧，而无恒心去完成它。

信心，一般来说，当一个开发人员想去完成一个Open Source项目，基本上会是，这个
项目对他而言是具备挑战性的，或者这个项目对他来说，技术难度性没有，但是存在这
较大的复杂性。这是就需要信心去完成它，要知难而进，特别是第一种情况。就如同，
Fayfay 原创空间中的脚本语言项目FinC。开始时我并没有把握去把它做出来，在兴趣
的带领下，在信心的守护下终于初具规模^-^

实践准则：
Small Release，尽可能快速的发布release，哪怕只是一点点改变。Open Source软件
仍然还是存在这开发人员和用户。对开发人员来说，尽快的发布能够增加他的信心；对
用户来说，能够增加其关注度：哦，这个项目仍然在发展。反过来也会带给开发人员更
多鼓励。同时最好和自己的计划接合起来，有一个明确的计划会鞭策自己去按时完成
它。
Refactoring，做为开发人员，你可以在每次release期间做大量的Refactoring，从而
使得项目软件趋向稳定，结构趋向最优化。当然，在每次release时，除了
Refactoring，bug fix或new feature是必须的。
Metaphor，做为协同开发而言，最开始时最好有一个简单的体系框架，但是不一定要很
全面。全，意味着需要时间的延长，对协同开发者而言则是兴趣的磨损。
Hack，当你觉得和你协同开发者开发的软件有些不如意时，可以试着去Hack，这也是了
解其他模块细节的良好机会。同时要强调一点的是，协同开发者之间并不一定要对对方
的细节了解得（非常）清楚，也就是说，协同开发者并不需要对自己所开发的这部分做
详细的分析及设计，等文档出来了，可能就在想着真实的东西什么时候才能开始的问题
了。（兴趣可以说就是这么一点一点的流失的……）相互之间的依存主要靠：Metaphor
和Interface（接口，相互之间的API）。而Interface可以采用跌代的方式，一步步把
它补全。
Cooperation，协同开发者最好采取谨慎的原则，主要要从兴趣的角度来考虑。FinC
曾经提过吸取协同开发者的准则，不防拿来一观：
是否对FinC真的感兴趣？对于想加入FinC合作开发的同好者，我希望您能够参考：
1、您是否已经针对于FinC提供了一些bugs report？并试图去解决它？
2、您是否提供了一些patch？
3、您是否对FinC的框架已经比较熟悉，或者对FinC的一个方面已经比较熟悉？并试图
提出一些合理意见？
4、您是否有足够的时间去了解它，开发它，使用它并发展它？
不要在你没release前就发布在网上寻找协同开发者的消息，除非你们关系非常亲密。
当你release第一版本时，自然会有人关注，而且别人也能够触摸（XP的代码的味道
：）！
Test，不要试图让别人来帮你做Unit test和所有的Functional test，Unit test基本
上是白盒测试，还是要依靠自己完成，而自己也要做完大部分Functional test。而让
用户来帮你做Functional test取决于你这个项目软件的用户群大小。
Documents，不要试图输出完善的文档，实际上这个在前面已经提及了一些，完善的文
档无疑是对开发人员和用户的耐心的折磨。

5.后记
希望本文能够帮助你提升Open Source项目的效率，如果你觉得有效，不妨给ffxz一封
email以鼓励;-)
本文您可以在Fayfay 原创空间(http://fayfay.gnuchina.org)上获得最新版本，同时
也非常欢迎您把您的Open Source项目经验反馈给我。

荔园在线首页友情链接：深圳大学深大招生荔园晨风BBS S-Term软件网络书店