[极限编程] XP之我见
2008-02-28 09:38:00| 分类：
scm
| 标签：
|举报
|字号大中小 订阅
近几年，敏捷软件开发方法炒得火热，但自己对这方面一直不了解。最近看了些xp、scrum 方面的资料，对xp有些了解，这里结合自己所在项目的情况，对比讨论之。
[* 项目背景 *]
本人参与一款游戏的维护一年多。目前项目的开发/维护流程是：
上周五，策划提出下周希望更新的内容（维护需求），程序确认完成所要花费的时间，并与策划讨论，根据维护需求的重要性，排出各项维护需求的优先级。最后再确认一次下周放出的内容，策划将这些内容发布到bugzilla上。（提表单）。
接下来的时间，程序根据bugzilla上的表单，开始开发工作。每完成一项，就 close 对应的表单，并知会QC同学开始测试已完成的内容。直到所有内容都通过QC测试，一周的开发内容也算正式结束。
周四早上维护，将一周开发的新内容放出。
[* XP实践 *]
XP软件开发方法讲究12中具体的实践，下面是12种实践的解释以及自己的一些理解。
Small Release（小版本），极限编程在一个或几个迭代周期结束后，就向客户提供一个版本。
这与我们每周维护很类似，每周发布一个新版本。
Planning Game（规划游戏），极限编程中，软件需求的记录有点像日志的形式，称为用户故事。客户负责编写用户故事。而程序员对每一个故事所需的开发时间做出估测，并且提醒客户有关的潜在技术风险。然后，根据所估计的时间基础，客户决定故事的优先级，即决定它们会怎样分配到各个迭代过程（或是小版本）中进行开发。
Planning Game 就是策划和程序员坐在一起，策划提出新的一些改动需求，每条需求就是一个用户故事；程序员则对每条需求进行开发时间评估，最后两方讨论出一周内（一个小版本）需要完成哪些需求。
On-Site Customer（现场客户），由于用户故事并不像传统的业务需求文档那样有具体而明确的细节，程序员需要随时向客户提出咨询。
我们项目中的现场客户就是策划，我们对策划文档中不明白的地方，随时向他们咨询。
Metaphor（隐喻），设定极限编程项目隐喻的前提，是所有的项目参与人员都必须对相关的抽象概念有统一的、具体的认识。
对于隐喻，自己还是不太理解。只是觉得这是要求程序员尽量熟悉客户的工作内容，用客户的语言和他们沟通。在我们的项目中，就是程序员应该尽量熟悉自己的游戏，才能更有效地与策划沟通。
Simple Design（简单设计），就是编码时，程序员只依据当时的需求编写代码，而不必为可能会发生的改变或扩展考虑。
我的理解是，对于一个游戏后期的开发（主要是游戏的玩法），Simple Design 是很好的，策划在玩法的变动上比较快，而且开发时间也比较紧，代码就以满足策划的具体需求为主。不为不存在的需求作设计。而对于前期的开发，比如游戏引擎、基础的游戏模块，好好设计下，还是很好的。
当然，Simple Design还表示程序员尽量选取简单、实用的算法来实现功能模块；也表示代码的可读性、可维护性要好。对于这方面，Simple Design在开发的任何时期都是必要的。
Refactoring（重构），用更简洁、直观的代码来代替原来难懂、繁琐的代码。
Test-Driver Development（TDD，测试驱动开发，也叫 Test-First），要求程序员对完成的每段代码都要编写相应的自动化单元测试用例，这不仅是一种编程方法，也是一种驱动软件设计的手段以及一种确保对代码有充分测试的途径。
我们传统的流程是程序员编码 -> QC测试。而 Test-First 讲究的是 unit test 先行，在写每个新模块之前，先将其的 unit test 代码写出来。撰写 unit test 的时候，就可以思考新模块的函数接口应如何设计，从而促使程序员设计出更好的模块。个人觉得，新开发的项目，一开始就使用 Test-First 驱动整个开发，对于后期修改程序，又同时保证程序的稳定，大有裨益。相反，对于成熟的项目，之前没有使用 unit test 驱动（我所在的项目），再希望加入 unit test，成本就非常大了。
另一方面，我认为并不是所有的模块都需要写 unit test，因为有些模块，比如复杂的游戏玩法不是十分好写 unit test（也许是我水平有限），再比如节日活动玩法，只放出几天，没必要专门再花时间写 unit test 了。
Continuous Integration（持续集成），关键在于当天必须完成所有代码的集成。
这一点，我们的项目并没有严格的要求，只是要求每次 commit 的代码都是可编译、可执行的。对于较大的改动，就 make a branch 去做了。而且项目并没有 unit test，每天集成起来也不能很好的检验程序是否有bug。（难道要QC同学每天不停地回归测试？- -b）
Pair Programming（结对编程），是两个程序员坐在一台计算机前，合作完成同一个编程工作，包括：设计、算法、编码和测试。
Pair Programming 是xp中的核心实践，也是最受争议的一项。目前自己是没有亲自尝试过，但根据《超越》[1]中的理解，并不是所有的程序模块都需要Pair Programming。Pair Programming对于较难的程序模块（比如游戏的战斗系统、任务系统），能起到比较好的作用，可在相对较短的时间内，开发出更高质量的代码；而对于重复性的模块实现（比如一个普通的游戏玩法），且程序员本身也十分熟悉如何coding的情况下，Pair Programming将大大不如Solo Programming高效。
不过 Pair Programming 的另一个好处是，保证任何一份代码，都有两个程序员对其比较熟悉，保证一人突然离开时，整个项目不会受太大影响。
Collective Code Ownership（代码共有），指代码的任何部分都不是某个人单独拥有的和维护的，任何人在任何时候都有权对代码作出修改，以增加新的功能、除错或进行重构。
个人理解，其实就是项目的代码对项目里的所有程序员开放，让每个成员都能了解项目代码的全貌。这一点对于我们的项目，基本上是一致的，服务端程序员有权利修改任何部分的服务端代码。
Coding Standards（编码规范），必须建立一个所有人都遵守的编码规范，以方便整个小组的工作，使整个程序风格一致。
我们项目中的代码虽然相对比较整齐（每个程序员自己遵循一套自己的风格），但项目还没有定制一套规则，强制每个人的执行。个人觉得，有一套强制的规范，可以使同一项目的代码更加统一，更便于维护。
Sustainable Working Hours（每周40小时的工作制），当今的IT行业中，员工的工作越来越忙，有时不得不先处理某些事情，如收发电子邮件、出席无休止的会议，等等。而把真正重要的事情搁置一旁。极限编程不赞同长时间工作，而希望工作时间内，程序员能100%投入。长时间工作带来的负面效应还有员工健康、情绪低落等问题。
在自己的维护工作中，项目比较紧的时候，长时间工作是再所难免了。但有一个方面倒是我们可以改进的地方——不被打扰。程序员在写代码的时，很怕被别人打算思路，而邮件、IM消息以及策划的口头需求，都是打扰的来源，比如每天收到的 IM消息，估计 80% 都不是必需立即处理的。因此，我们是否可以每天由一个程序员，接管项目中所有其他人员的 IM、邮箱，只在有紧急信息的时候才通知coding中的程序员；而对于策划的口头需求，可以通过“将一天的小改动积累到第二天早上一次交给程序员”这样的方法，减少打扰。
[* 总结 *]
XP的软件开发方法不可能适合所有软件项目，而对于小团队，且需求变化比较快的项目比较适用。我们游戏开发可归为此类吧。
我们目前的开发方式，也算是部分的XP吧，虽然还有很多可以改进的地方。 :-)
当然，是否使用XP并不是项目成功的关键。而是，借用朋友的一句话：“按照团队的情况使用不同的XP实践，团队的能力和Best Practice是项目成功的关键”。
[1] 强烈推荐一本书《超越传统的软件开发方法——极限编程的幻想与真实》，几位香港大学教授的作品，内容翔实，实例具体，实为理解 xp 不可多得的资料。可惜 china-pub 已经绝版，买不到了。
评论这张
转发至微博
转发至微博
关闭
玩LOFTER，免费冲印20张照片，人人有奖！
我要抢>
<#--最新日志，群博日志-->
<#--推荐日志-->
<#--引用记录-->
<#--博主推荐-->
<#--随机阅读-->
<#--首页推荐-->
<#--历史上的今天-->
<#--被推荐日志-->
<#--上一篇，下一篇-->
<#-- 热度 -->
<#-- 网易新闻广告 -->
<#--右边模块结构-->
<#--评论模块结构-->
<#--引用模块结构-->
<#--博主发起的投票-->
评论