关于奥普迪词典软件竞赛的一点体会、抱怨与建议

关于奥普迪词典软件竞赛的一点体会、抱怨与建议

下面是我们（StoneAge小组）对本次活动的一点体会，也是我们想说的一些话，一些抱怨与建议：

 

一、本次赛事的目的

1. 奥普迪公司

开门见山。据我们了解，奥普迪公司正在做外语学习软件的suite package。以奥普迪公司的角度，产品化，或者部分产品化本次竞赛的结果是必然的。As everybody known, 日本奥普迪公司主要是做外包项目的，而外包项目也许永远也不能把自己公司的牌子打响。所以，在时机成熟时，做属于自己的产品是必须的。从大赛计划书后面关于lisence的声名与后来一系列会议的内容看，确定无疑。

 

2. 云南大学软件学院

作为学院，能与校外的公司共同举办这样的活动的很不错的。既可以培养学生的实践能力，也可以把部分学生的实习问题解决，何乐而不为？

 

3. StoneAge小组

锻炼了自己，从团队管理，软件过程组织，技术开发等都是一次难得的锻炼机会。对于赛事本身，我们的目的也很明确：大奖，架构设计奖，编程奖，队员也能够得到去日本奥普迪公司的实习机会。从团队的人员组成上来看，我们绝对拥有这个实力。在实践的过程中，我们也很认真，团队Blog、项目管理软件、团队协作软件、配置管理软件的使用都恰得其当，很愉快。

 

 

二、赛事的组织与管理

本次活动始于2007年10月，主要针对的参赛者是2005级的我们。但是在2007年秋季学期中，学习任务相当繁重，所以在2008年寒假以前基本没有小组认真对待这件事。我们认为，这是客观原因，那段时间课程实在压得人透不过气来。所以，各个小组基本是没有什么实质性的进展可言。

记得第一次开会，刘永昆经理说了一些话，关于软件项目管理的，关于软件过程模型/方法论的。但是给我们的感觉就是云南奥普迪这边对本次竞赛的关注好像并不是这么高。不过，有一次会议时，刘经理说：“不愿意看到我们又做出一个类似金山词霸的作品”；而张一凡老师则说：“再做出一个金山词霸也是一次不错的学习机会”……矛盾之处骤然展现。

后来的会议很零散，很涣散的感觉，也许是大家都太忙了。

开学后，李涛社长亲自从日本赶过来，连开了三次会，足以说明奥普迪公司对本次活动的重视与关注。但是，对于本次活动的最终目的来说，这是远远不够的。原因在于奥普迪与我们对于项目的认识都不是足够清晰。虽然奥普迪公司的目的在上面已经提到，很清晰，但是对于目标如何实现、如何带领员工往这个目标一齐努力做得还不够，至少我们是这样认为的。不过对于我们要做什么终于明确了——需求、Idea。

记得在最后一次会议，一位技术负责人最后强调了一次需求。对我们来说，是我们的需求，我们终于明了化了我们究竟要做的是什么；对赛事本身来说，也明了化了它的最终目的。这次会议总结了前一阶段，可惜，来得晚了点。

不过，至少有一点可以肯定，奥普迪公司非常想做这个项目，可是我们认为方法上存在问题。

同任何软件项目一样（也许不同于外包项目），我们（奥普迪与参赛者们）遇到了需求不明确（或者说是完全没有需求，由于项目本身的特殊性）的问题，更要命的是我们应对这个问题时候采取的解决策略是不明智的，原因如下：

1. 项目管理存在严重问题

高层（奥普迪公司）对于这样一个以创新为首要目标的项目来说，项目管理存在严重问题。在这个赛事的过程中，奥普迪公司一直强调这个项目不是朝夕之事，这一点我们很同意。奥普迪公司与云南大学软件学院的合作已经有3年了，我们也深信这样的合作可以继续下去。在以往的几次会议中也多次提到：“这个项目不只有2005级的学生可以参与，06、07的学生要继续下去，甚至是你毕业后，也可以参与到其中来！”可是……试想，这样一个项目，How big it is! 从软件系统本身的角度看它并不算多大，但是，它涉及到的人、资源、时间是多么的可观啊！它的确很大了，这样的一个项目，项目管理不做好能够成功吗？这只是本项目的第一年，就已经这样了，那明年、后年、将来呢？

 

2. 整个项目的过程模型有问题

做任何软件项目，离不开过程与过程模型。众所周知，过程模型是过程的静态描述。所以，过程模型的选择对于项目的成败至关重要。据统计，虽然现在60%的软件项目都是使用的Water-Full，但是这并不能证明只有瀑布模型才能成功地完成项目目标。按照奥普迪公司目前的做法，是纯粹的瀑布模型：今年完成需求的主要部分，明年开始设计、实现……

这样的做法对于一个连需求都不确定的项目有帮助、指导的作用？

 

3. 迭代式过程模型

迭代过程模型有很多，特别是面向对象的迭代模型。说到开发方法，OO显然是首选，以OOSE（面向对象的软件工程）的方式进行项目是我们的目标。方法论从理论上的迭代模型、喷泉模型到有实际意义的UP，最近很热的Agility Methodologies（敏捷方法）都是我们值得实践的。

 

4. Agility Methodology

敏捷方法最早可以追溯到1992年，[Jack W.Reeves 1992, 什么是软件设计]的论文提出了源代码就是设计的论断，对现在与将来的影响是深远的。敏捷方法在2001年正式提出，可以说敏捷方法是对几十年来软件工程方法论的总结。《Extreme Programming Explained：Embracing Change》这本书是XP（极限编程）方法论创始者Kent beck的大作，书中讨论了传统过程的问题，诠释了XP的精髓。可惜，国内跟风盛行，对XP有很多屈解，并不是一拿到需求就进行编码就是XP，XP是有严格的项目管理的，各个阶段、活动、任务是有条不紊地进行的。从大一下学期我们第一次接触XP到现在，我们做了很多以XP为指导的实践项目。结合本次项目，我们认为敏捷方法中的XP是最适用的方法论！XP的核心是由一系列简单却互相依赖的实践组成的：

(1) 客户作为团队成员

作为需求的制定者，创意的提出者，我们与奥普迪公司都可以扮演本次项目的客户角色，而且，在项目过程中，团队中的每个个体确实是可以在一起工作，没有特别难以克服的物理问题。不存在分布式项目（例如海外、跨区域外包项目）的问题。

(2) 用户素材

在每次与奥普迪公司会议时，我们都以简要的纪录作为一些需求的获取手段，在进行创意需求时，我们也适用用户素材的方法进行需求获取与描述，而不是大规模、不成熟的需求文档。

(3) 短期交付

通过对项目管理软件/团队协作工具（Mingle）的使用，我们以每两周一次迭代的周期实现一些需求。每次进行迭代计划时我们都根据与奥普迪公司会议中的内容调整用户素材的优先级，并将这些素材分解成一系列的任务加以实现。在发布计划的中，我们制定了大约5次迭代后的第一个里程碑（MileStone）版本，并顺利实现了这个里程碑的发布。

(4) 验收测试

本次项目由于其特殊性（客户就是开发人员），所以我们并没有由专门的客户指定验收测试（Acceptance Tests），也正由于本次项目的特殊性，所以我们认为验收测试可以暂时忽略。

(5) 结对编程

目前代码的大部分关键代码的确是由团队内以两个程序员为一组的方式，在同一台电脑上完成的，这样的工作方式极大促进了知识在我们团队中的传播，比任何以培训方式传播知识快得多，而且代码质量很好！

(6) 测试驱动的开发方法

我们使用测试驱动的开发（TDD）进行项目，这样的开发方法让我们不会偏离我们的需求，用最简单的实现满足需求。在明确用户素材后，我们编写了很多测试用例，这些测试用例既是对需求分解后得到的任务的代码呈现，也是我们在重构代码时的重要支持，让我们的重构不会偏离需求。最重要的是这野开发方式让我们的OO系统中的组件保持了很低的耦合度，对面向对象设计提供了巨大的帮助。

(7) 集体所有权

结对编程时，每一对程序员都有对任何模块代码修改的权利，没有程序员对任何一个特定的模块或技术单独负责。在结对时，我们组的每个人都参与贵GUI方面的工作；每个人都负责核心数据结构的改进；每个人都参与持久化方面的工作。没有人比其他人在一个模块或者技术上具有更多的权威。特长是GUI的组员经常被邀请去参与数据库或核心的开发，大家都在互相学习。

(8) 持续集成

我们以SVN版本控制系统作为源代码库，任何组员都可以随时迁入/提交（check-in/commit）代码；任何时刻、任何组员都可以进行代码的合并（merge）与构建（build）。在每次提交代码时，我们规定了必须写提交注释（commit comments），以使得其他更新、合并代码的组员知道代码的修改部分和注意事项。

(9) 可持续的开发速度

从2月1日我们正式开始项目，我们都有意识地保持稳定、适中的速度进行项目。像前面（二、1）提到的，这是一个很巨大的项目，我们把这个项目看成马拉松长跑，不管在什么阶段我们都很清醒！

(10) 开放的工作空间

我们团队一直都在5楼的软件工程实验室（除了假期时），有问题时我们可以很方便地进行讨论。

(11) 计划游戏

计划游戏（planning game）的本质是划分业务人员与开发人员之间的职责。业务人员（也就是客户），决定特性（feature）的重要性，开发人员决定实现一个特性所花费的代价。同样，由于本次项目的特殊性，在这方面我们没有必要作严格的界定。

(12) 简单的设计

在开发时，我们一直考虑的是能够工作的最简单的事情，能使用文本文件保存信息时我们就不会去使用数据库，能够使用socket我们就不会去使用ORB或者RMI。在这个项目中，所有的一切（包括我们自己制定的需求）都是不稳定的，所以我们只编写能够工作的代码，如果有一天发现需要进行架构、技术方案的调整，我们就去调整它。在本次赛事结束时，我们写了一篇文章——《设计演化与设计》，其中简述了我们的设计是如何逐步演化的，提出了“软件设计演化远比软件设计本身更为重要”的论点。

(13) 重构

在本次开发过程中，我们一直在不断地重构代码，只要发现代码中有Bad Smells，我们便马上进行重构，让代码更容易维护和扩展。在重构时，《重构——改善既有代码的设计》、《重构与模式》两书常办我们左右，一边学习一边实践。

(14) 隐喻

在基本的特性（参看第三节）确定后，我们逐步将系统实现框架迁移到了OSGi上，基于组件的服务架构就是我们的基本架构思想。想想Eclipse就知道了！

当然，上面结合XP实践说了这么多，只想说明一点：本次项目的确适合以XP作为方法论！不过，以上所有都是基于一个假设的：奥普迪公司非常愿意与云南大学软件学院、与学生一起共同完成这个项目。

 

 

三、在线、开放式词典的意义

我们组内有同学参与了NetBeans中文翻译组、Spring2.5.x参考手册翻译组，其翻译项目管理得都很好。在此类翻译项目中，都是以团队WiKi的形式进行管理。大部分翻译问题通过查阅项目组内的术语表，参与邮件列表讨论即可方便地得出答案。对于专业翻译组的人士，用得着一个这样的词典吗？

我们把问题扩大一点，假定某术语表是全球范围的，以方便用户在不同context中进行翻译术语的查阅，有了新的术语也可以添加经来，并与时俱进。这……难道不是Wiki吗？？？？

什么是Wiki？

Wiki一词来源于夏威夷语的“wee kee wee kee”,原本是“快点快点”的意思,被译为“维基”或“维客”。
    一种多人协作的写作工具。Wiki站点可以有多人（甚至任何访问者）维护，每个人都可以发表自己的意见，或者对共同的主题进行扩展或者探讨。
    Wiki指一种超文本系统。这种超文本系统支持面向社群的协作式写作，同时也包括一组支持这种写作的辅助工具。有人认为，Wiki系统属于一种人类知识网格系统，我们可以在Web的基础上对Wiki文本进行浏览、创建、更改，而且创建、更改、发布的代价远比HTML文 本小；同时Wiki系统还支持面向社群的协作式写作，为协作式写作提供必要帮助；最后，Wiki的写作者自然构成了一个社群，Wiki系统为这个社群提供 简单的交流工具。与其它超文本系统相比，Wiki有使用方便及开放的特点，所以Wiki系统可以帮助我们在一个社群内共享某领域的知识。
    Wiki发明者是一位Smalltalk程序员沃德·坎宁安(Ward Cunningham)。

 

Wiktionary项目！

这是一个创作自由的多语言词典的协作计划，它包括每种语言的语源、读音和解释。维基词典中文版始于2004年5月，现在已经有 115,551个词条。任何人甚至无须登录就可以编辑任何字词。请参见常见问题和帮助来获得有关如何使用本网站的更多信息。维基词典中的内容均在GNU自由文档协议证书下发布，这意味着它将是完全自由的。详细信息请参见版权。

 

全球最大的Wiki站点Wikipedia下面早已存在这样一个开放式、实时的在线词典了！那究竟这个项目的意义何在？记得李涛社长在最后的一次会议里提到：“大学范围内的开放式词库”，如果我们把项目的范围控制好，在大学间先推广还是有机遇的。但是，考虑以后的扩展的话，技术方案的选择就至关重要了。目前各类WiKi站点的一个共性是：大而不专。如果我们以专业社区为单位，社区内部类似以WiKi的组织方式的话，可以有一些实际的意义。

 

 

四、我们的Ideas

假设我作为用户，我为什么要选择这个词典服务呢？——业务模型分析文档，SWOT

但作为赛事的必须交付件之一，业务模型分析文档所描述的内容自然要往“好”的方面写，要往对于我们组有利的方面写。但是，这样无用的东西应该不是奥普迪公司所期望的。当然，我们组是这样的，其他组也许比我们务实。To such a Online/Open Dictionary, 我们想象过很多Ideas，开发过部分Fuctions。但是，在接近提交作品的现在，我们想说：“we have been do our best！”。我们的业务模型与用户需求素材已经在其它文档中详细描述过了，其中最主要的Ideas，或者说是我们这个词典的Features有如下三点：

1. Services Based on Community

用户到底会不会选择我们以社区方式的服务？社区的管理会不会混乱？用户的贡献（提交新词汇或修改已有词汇）在社区内的审核如何降低审核成本？

²  关于社区式服务，我们认为用户是乐于使用的，一个词汇在社区里可以得到这个社区范

围内方面最权威的词汇定义；

²  此类社区的管理需要富有责任心的人，或者是专门从事社区管理的负责人；

²  为了保证词汇的权威性，必须有专人对词汇更新进行审核，在审核的过程中，可以借助一些自动化程序降低一点审核人员的负担。例如过滤垃圾信息、重复词汇解释的判定。

 

2. User Dictionary Subscription

用户词库到底作用有多大？会有多少人实际去使用它？

²  用户词库的作用要根据用户角色来划分，如果一个用户的职业是翻译或者教师，那这个词库对于他来说就意义重大。他可以将自己的词库共享给信赖的好友，以期更新词库，共享词汇信息；

²  我们认为应该有一定的用户群，特别是在学校范围内。

 

3. Vocabulary/User Rank

用户是否愿意参与评级？用户会参与词汇/用户评级的策略会不会有用户恶意刷等级，从而造成混乱？

²  评级很方便，鼠标点一下即可；

²  破坏社会秩序的人总是存在的，但总有办法逮到他们的！

 

不过，说到底，实践是检验真理的唯一标准，我们认为，这些问题不是调查能够解决的，Practice it ONLY！

 

 

五、软件工程

根据软件工程的定义：软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。

根据我们现在的理解与经验，以产品过程看，需求是核心；以实现过程看，技术是重点；以团队组织看，人与人之间的交互（communications）是要素。三者不可分割，同样重要。而软件项目管理是围绕这三点展开的。

1. 需求

需求是对软件复杂度（分析/设计/实现复杂度）影响的最大因素，需求的不稳定性直接造成了软件开发的困难。对于需求变化，我们应该持积极态度，做到一切变化都Under our Control！

2. 技术

现在，流传着这样一个观点：只要需求分析好了，需求确定了，技术不是问题。我们认为这样的看法过于片面，技术的选择对整个软件生命周期有着很大的影响。逐步演化出的架构决策、设计在很多项目中会比一次性决策、设计有更好的适应性（参看《设计演化与设计》）。技术是我们在本科阶段一定要学习，并且在某个技术方向一定要深入学习，没有技术，一切都是空谈。记住，“可工作的软件胜过面面俱到的文档！”——敏捷联盟宣言。

3. 人

人与人之间的交互式复杂的，而且其效果从来都难以预测，但却是工作中最为重要的方面——Tom DeMacro 和 Timothy Lister《人件》，第五页。也正如 Alistarir Cockburm 所说的，“过程和方法对于项目的结果只有次要影响，首要影响的是人。”所以，处理好个人问题，处理好团队问题，处理好与客户的问题是项目成功的首要因素。

 

虽然我们入行尚浅，但作为软件工程专业的学生，作为中国软件行业的接班人，我们看到有很多悲哀的事：在工业界，某些公司为了CMMI的评级而只在表面上下功夫，视那些“非正规的”方法论为粪土；某些公司为了按期交付产品而强制员工加班，直接威胁到了员工身心健康；某些公司只为了交付软件而编写软件，在表面文档上注重产品的质量属性。在学术界，国内论文抄袭现象泛滥；各类创新项目没有任何实际意义……

痛定思痛，一想到这些，黯然泪下。但是，肩上的责任时时刻刻都在提醒着我们，为了中国的软件行业发展，为了世界各地的软件行业发展，为了全人类生活的改善，我们将义无反顾地奋斗下去！

 

[后记]

写下这些文字前，我们考虑过，想象过这些文字带来的结果。但是，这毕竟是心里所想，也许也是很多人想说的话，不吐不快；

在写这些文字时，我们激情澎湃，勇气、青春的热情更加坚定了我们的信念，初生牛犊不怕虎；努力奋斗、感慨万千过后，我们感受到了我们自身的成长。所以，我们满怀信心，静静地期待结果，期待伯乐！