隐喻和计划游戏

免费打工仔

原文地址

设计上的实践

好了，在上一篇日记中我们实现了一些简单的用户素材，对整个工程的需求也有了一定了解。现在让我们进行进一步的实践。

隐喻：号称极限编程中最难理解的条款，也是极其重要的条款，甚至说要代替框架设计。

我一直喜欢把游戏比作电影。Orz框架中充满了导演、演员以及场景的类型，那么AVG框架是什么呢？

在我这次开发中，我们把AVG这种单一的游戏类型，理解为某一种类型影片，例如动作片=动作游戏，侦探片=推理游戏，魔幻据=RRG，小品=益智游戏，故事片=AVG。除了哪些特别厉害的导演之外，大部分拍摄某种类型影片都有一定规则和流程，比如侦探片一定要在故事的前半段出现谋杀，爱情片一定要有第三者，动作片一定会有一个主角的对手和Boss出现。这些不同类型影片的拍摄经验会记录在一些影视教科书中，新的导演可以从中吸取很多前人的经验，然后再谋求突破。

完整的游戏就是一个完整的电影，开发者作为制片人，负责调配整体。首先制片人应该考虑拍摄什么类型影片（游戏类型）。然后从已有的教科书中寻找资料（AVG框架），最后根据需求配置导演（Director类型），场景（Scene类型）以及演员（Actor类型）。最后把剧本（脚本）提供给导演和演员。让导演去拍摄这个电影（运行游戏）。

在上面的隐喻中，我们可以看出AVG框架最重要的功能就是提供一个通用的知识仓库，再重复一下，就是《Unix编程艺术》中所说的机制。而插件们（导演、场景、演员）负责提供游戏的具体内容，换句话说就是《Unix编程艺术》中所说的策略。

就算没开始之前，我们也需要确定几个原则，机制和策略分离、系统和逻辑分离。

计划游戏：

在上一篇日记中，我们已经提供了几个简略的故事卡片，现在我们需要制定一个第一次迭代计划。我们需要一个可以切换2D（或者3D）场景的框架（第一张故事卡），这就足够了。第一次迭代尽量简短，这样有助于我们更好的估算自己的工作效率。

1. 
   
2. 通过脚本配置场景 我拷贝了两张图片到资源目录下，然后通过脚本控制显示哪个图片作为场景。
   
3. 测试1：拷贝两张2D图片，运行程序，然后通过脚本切换，能正确显示预计结果。
   
4. 测试2：测试3D场景，效果和上面一样。
   

复制代码

首先我们先去掉脚本方面的应用，单独实现场景管理。（脚本放在下一次迭代过程）。

因为我本人是业余时间搞这个开发的，时间估算难度很大。优势是没有所谓的老板来催促进度。那么我们就相对放宽松一点，便于我们更多的分析开发过程中所遇到的问题。每次我写日记的时候，就是我能开发的时候，作为一个日记工作日。我们先把这个任务确定为5个日记工作日吧。根据极限编程的经验（书里面写的），这个时间估算很可能会出问题，一定会有一些调整，但是这个“错误的”估算会帮助我们之后得到更准确的估算。

开发流程的讨论

虽然我们到目前为止还没有正式开始进行任何编码活动，却已经简单的实践了极限编程中的很多方法。

1客户作为团队成员：因为我本人既是客户又是团队，天然实现。
2用户素材：在上一篇日记中我通过自言自语的方法讨论出了一些简单的用户素材，实现。
3短交付周期：没实现。
4验收测试：没实现。
5结对编程：因为我只有一个人，天然无法实现。
6测试驱动开发方法：没实现。
7集体所有权：因为我只有一个人，天然实现。
8持续集成：没实现。
9可持续地开发速度：没实现。
10开放的工作空间：因我只有一个人，天然实现。
11计划游戏：本日记内容，实现。
12简单的设计：在设计过程中，已经部分实现。
13重构：没实现。
14隐喻：本日记内容，实现。





如上图所示，你会发现一些有趣的现象，所有的前期实践都出现在这幅图的左边（除了简单设计这个“规则”之外）。根据这幅图我在这里做一个不权威的假设，XP设计的首要条件是客户作为团队成员，而XP开发的首要条件是测试驱动开发。因为根据他们作为叶子节点让整幅图天然的划分成为左设计、右实现的样子。

以上只是我个人的看法，不保证正确，还望大牛们多多批评指导。

原文地址

lpjias

很是深奥，没看懂多少~~~~

免费打工仔

lpjias: Re:隐喻和计划游戏

很是深奥，没看懂多少~~~~

没错，在极限编程中 隐喻 和测试驱动或者重构这些很容易理解的概念不同，很抽象，难理解，但却是XP设计中不可缺少的一环。因为XP历来有简单设计的原则，快速迭代。少量的讨论，很容易导致开发人员之间的观点不同，每个人都面向着不同方向前进，这就导致XP编程的能量下降。

而和传统的开发模型不同，因为“少量设计”，所以不能也不建议在正式开始编码前就完成一个完整的框架设计，且就算有完整的框架设计也会在XP中被重构和迭代击垮。所以这么就很容易理解隐喻的作用了，隐喻是一个只提出方向而没有细节的框架设计，这样既不会限制代码的具体细节，同时会提供一个总体的方向。

谢谢你的帖子，让我深入的思考了隐喻的作用，但是这只是我个人的看法（以及从网上搜索的一些资料）。不代表真正的正确性。我建议因为隐喻的成本较低，不如在下次编码的时候，大家都试验一下，可能会发现隐喻的好处。