游戏力量资料站

第一部分 拆分功能模块 

一个完整的功能模块包含“先决条件、操作、结果、冲突与联系”四个部分。在拆分功能执行案之前，首先会拿到一个框架案。试开发流程的不同，他有可能来自项目内某人的口述、框架案文档或撰写功能执行案的人自己设定。

那么，我们首先来看一段框架案：

①     商城分充值与消费两大部分，充值通过页面操作进行，消费在游戏内进行。

②     点券的获得：用户通过账号充值获得点券。

③     点券的消耗：购买商城内的道具消耗点券。

④     有新品和热销商品的标示。

⑤     商城购买的道具不可出售给系统。

⑥     商城的道具分类沿用商店的设定。

    好的，现在我们已经拿到框架案了，接下来让我们看看该做些什么。首先，这份框架案并不是按照用户操作流程撰写的，而只是将框架案的关键信息写出来了。而我么拆分功能模块的依据是用户的操作流程，那么让我们将上面的框架案转换成一个用户使用商城的操作流程。

①     商城的主要功能是购买道具，这是在一个游戏窗口上完成的。那么用户使用商城的第一个操作步骤是：打开商城。

②     相对于打开商城，一定有一个关闭商城的操作。因为用户需要退出商城进行其他的游戏内容。

③     获得点券是在网页上完成的，那么可以不放到功能模块中。

④     因为有道具分类，那么可查看之前的设定，因为之前不同分类的道具是在不同的标签之下。为了保证游戏内容统一，在我们这里也沿用标签的设计。所以需要一个切换标签页的功能模块。

⑤     商城的主要功能是进行虚拟道具的购买，那么我们需要一个购买道具的功能模块。

⑥     商城购买的道具不可出售给系统：商城购买的道具将存储到用户仓库内，而不可出售给系统的操作是在用户仓库内完成，不属于商城系统。所以不需要在该功能执行案内列出单独的模块。

⑦     新品和热销商品的标示，首先新品和热销商品的显示不是用户操作的结果，而属于打开商城后，商品的显示规则。那么我们可以单独列出一个模块，我们称为商品排列规则。

⑧     另外，为了帮助用户挑选商品，我们需要提供商品信息的显示。所以可以单独列出一个功能模块查看商品信息。

⑨     商品的数量可能大于一页，那么我们还需要一个功能模块：翻页。

    到此为止，我们已经列出了商城系统的完整功能，并且可以得到下面一个描述商品系统功能的简图（图例1）。虽然这个系统相对简陋，但至少是完整的。实际上，我们可以至少往里面加入如下的功能：赠送商品、试穿商品、购买试穿、快速充值。

    在我们看完了操作实例后，我们开始需要一些具有适用于所有功能的理论基础了。这将有助于功能执行案的撰写者，搭建合适的功能模块。那么满足什么样的条件可以独立为功能模块呢？归总起来就是以下几句话：

1.      用户的一次操作是一个独立的功能模块。

2.      系统处于某种状态（不需要用户操作）后的结果可以是一个独立的功能模块。

3.      特殊的需要程序注意的内容（只包含冲突与联系），可以是一个独立的功能模块。

图例1 商品系统功能简图

依次解释以上几句话。

用户的一次操作是一个独立的功能模块。

    用户的操作可能是如下几种：

①     鼠标左键单击某按钮/角色/图标/窗口某位置，扩展一下，还包括鼠标右键、鼠标中键、双击、长按、拖动。

②     按下键盘某按键，扩展一下，还包括按住、按击数次。

如果是PC游戏就是键鼠操作了，没有其他。那么以上，每需要用户一次单独操作的功能模块都应该是独立的功能模块。

有的时候会出现这样的情况，完成一个功能需要依次完成两次操作。例如上例在商城中购买商品，有这样的实现方式：1.鼠标左键单击商品图标，选中商品；2.鼠标左键单击购买商品按钮，完成商品购买。类似这样的情况，建议拆分成两个不同的功能模块，因为他们可能有不同的冲突与联系，拆分成不同的功能模块，单个框的内容较少、且冲突与联系的归属清晰，易于程序阅读。

系统处于某种状态（不需要用户操作）后的结果可以是一个独立的功能模块。

    有些结果并不是用户操作的直接结果，而是当系统处于某种状态后的结果。这需要单独列出一个功能模块。理由是：单个框的内容较少、且冲突与联系的归属清晰，易于程序阅读。并且他们可能具有相同的特点，这也是让功能执行案易于阅读的方法。

    例如：商城打开后，商品的排列规则、商业页面上按钮的状态、标签的排列规则。当然，你也可以把他们写在同一个框内，但你将让程序阅读到一个长达2页，内容排布杂乱的功能模块。你有考虑过程序的心情吗？

    特殊的需要程序注意的内容（只包含冲突与联系），可以是一个独立的功能模块。

    这部分内容可能没有先决条件、操作、结果；而只属于冲突与联系。例如窗口中文字的大小、最大数量、图标大小、一页显示数量、标签分类等等属于约定性的内容。如果他们数量足够多，并且重要。你完全可以把他们列出来作为一个单独的功能模块。

    到这里，如何拆分功能模块已经介绍完了；但还有两点需要额外注意的：

    第一，功能模块的标题必须是对该功能模块作用的描述；有的人写的功能模块标题，甚至让人看了后完全不知道这是一个什么样的功能。这是多么糟糕的一件事情，如果我要在写末份功能执行案，需要查找之前功能执行案中的相关内容，却发现我不能通过标题去判断，坦白说，这一刻我想拿板凳砸人。

    第二，拆分功能模块并不是严格遵循框架案的内容；框架案只是约定和协助的作用。如果发现框架案的在设计上有不合理或冗余的地方，功能执行案的撰写者有必要提出异议。

下期预告：撰写功能模块……