HIT软件构造——从一个实际案例考察开发质量目标

在之前的文章中，简要陈述了一些软件的外部质量因素，但这毕竟只是纸上谈兵的介绍，那么在实际开发中，这些因素是怎么与软件开发过程和产品相互作用的呢？重要的是，用户视角下这些因素究竟对产品表现有何影响呢？下面会通过游戏《炉石传说》的例子详细陈述。

1.正确性

《炉石传说》的正确性一直受人诟病，例如，按照隐式的游戏规则，如果卡牌的描述语句中有多个行为，它们将按照卡牌描述中的顺序执行，但是，存在一些文本描述顺序与实际的方法执行顺序不同的情况，这会让玩家规划自己的行动时变得困惑。

2.鲁棒性

《炉石传说》曾经在程序层面最引人注目的特质就是极强的鲁棒性，无论发生了什么异常情况，游戏竟然都能（以一种诡异的方式）进行下去并且直到这局游戏结算，但随着程序变得越来越臃肿，这样的特质就一去不复返了，例如，在今年的一个bug中，仅仅简单地使用 布莱恩·铜须 重复 艾萨拉女王 的效果会导致游戏崩溃，这可能是因为 艾萨拉女王 的效果触发需要一个计数器，而这个计数器的值在被复制时没有正确地传递给新的对象，导致了异常。

 

 

3.可扩展性

可扩展性可能是《炉石传说》程序做得最差劲的地方。大多数bug都是因为差劲的可扩展性导致的，而它们中的很多其实完全可以通过更有前瞻性的开发避免。例如，在最初的游戏机制中，手牌上限为10张，当涉及到对全体手牌的操作时，一些卡牌的实现就没有使用手牌上限这个变量作为参数，而是直接用了10作为参数。于是，在后来推出卡牌 瓦迪瑞斯·邪噬 将手牌上限变为12张时，如果使用一些卡牌触发复制对方手牌或抽牌至手牌上限的效果，就只会复制10张牌或抽至有10张牌。

 

 

4.可复用性

《炉石传说》的可复用性也相当糟糕，有着大量描述相同却在结算时表现出不同行为的牌，这显然是因为此前为某张牌设计的方法没想到会在未来被大规模应用而没有考虑复用性，后来新的方法实现相同描述时会在特定情况下展现出差异，甚至更愚蠢的是，新推出的卡牌有着bug，而之前类似的卡牌却没有问题，这些都是可复用性差的体现。比如 双弓积骇纳迦 可以让 海盗将领钩牙 的效果错误的重复一次，但之前推出的 日蚀 就不会有这个错误。

 

 

 

5.可移植性

《炉石传说》可能是移植工作量最大的游戏，因为它的PC端与IOS/安卓共用一个服务器，玩家的数据，资产都互通而游戏玩法完全相同，还需要每两周全平台同步更新版本，为此，暴雪将其程序部门的很大一部分投入进来，一定程度上影响了开发效率，但鉴于它全平台的互通取得了游戏界前所未有的成功，这绝对是值得的。

6.易用性

此时，《炉石传说》的易用性与功能性可以合起来讨论，为了不引入复杂的交互，在很长一段时间内，一张牌最多只能选择一个目标，直到 哥利亚·斯尼德的杰作 发布，很大程度上改变了其UI的交互逻辑。

 

7.功能性

尽管在对战内容上《炉石传说》以卡牌游戏最简单直观的操作和UI交互闻名，但商业角度其功能性简直是彻头彻尾的失败。在一个原本成功的卡牌游戏内植入一个除了美术资源，其余几乎都无法复用的宠物对战游戏无论怎么想都是一个糟糕的决策。

8.及时性

我们会注意到，对程序员而言，尽早在时间限制前完成任务是职责，及时性或许是不需要思考的因素，而对于决策者，这其实已经超出了开发的技术知识，而变成了商业问题。例如，有谁能想象在自走棋模式的热度似乎已经过去的时候，姗姗来迟的 酒馆战棋 会成为《炉石传说》的救命稻草呢？（甚至在此之后《英雄联盟》也推出了自己的自走棋才证明这一玩法并未过气）但是，同样是暴雪旗下产品，姗姗来迟的《风暴英雄》最终成为一款失败的竞品，这背后涉及的商业原理非常复杂，就不在这里赘述了，而重要的是我们在参与决策的过程中要记得不要想当然，因为这可能是超出我们知识范围的事情。

9.经济性

作为一款卡牌游戏，《炉石传说》的优势在于其低廉的开发成本，然而，同样因为一个基本的团队就能维持现有频率的更新，其在听取玩家社区意见改善功能方面做得异常缓慢，这就是其经济性上的取舍，可以看出对于微软暴雪这样的大企业而言，经济性不是妥协，而是抉择，这是一个新的视点。

希望这些例子能让读者对软件的开发质量目标有更清晰的体会。