写了一个bug，最后却变成了feature，要不要修呢？

事情是这样子的，前不久接到一个需求，为一个游戏开发礼包码功能

通常一款游戏运营期间会搞各种各样的活动吸引玩家，其中最常见的就是发放礼包，  玩家可以通过礼包码兑换礼包。

用礼包码兑换礼包有个一限制，游戏运营商不会让玩家无限制兑换， 针对某一次发放礼包的活动，一个账号只能兑换一次， 即使玩家手上有多个礼包码也不能多次兑换。 打个比方，某一款游戏搞活动向玩家发放礼包，这个礼包内总共有10000个礼包码， 玩家可以通过这些码去游戏中兑换。 参加活动的玩家每人手上只有一个礼包码，而某一个玩家通过某种方法拿到多个这次活动的礼包码，那么当他登录账号去兑换这批码时，是不会成功的，他只能兑换一次，其余的码只能通过不同的账号去兑换。

这是面向玩的客户端逻辑。

在后端呢，有一套针对礼包的管理系统供游戏运营的同事使用， 当要发放一个礼包时， 他们可以在表单内填写礼包的名称、礼包码的数量、使用礼包码兑换礼包的道具之类的信息生成礼包， 然后把礼包码分给玩家。

这很和谐，一点问题也没有。然而这只是假象，我做的这个功能，在只发放一个礼包时是没问题的，但是要同时发放多个礼包， 就会触发一个bug。因为每次在系统中添加一个礼包后，在游戏中并不能直接生效，而是要使用系统提供的同步功能将礼包同步至游戏中。

人有一个特点， 做事情喜欢分类。比如说我们小时候做作业，肯定是先做完某一门功课的作业，再去做另一门功课的作业，我们不可能以做一道语文题，接着做一道数学题，然后再做一道语文题的方式来完成作业。人脑不是电脑，没有多线程， 事情只能一样一样做。

这下问题来了

运营的同事有时候会需要同时发放多个礼包，碰到这种情况，他们的操作步骤是

添加礼包，添加礼包，添加礼包，同步礼包到游戏，同步礼包到游戏，同步礼包到游戏

而我开发程序时根本没有想到会出现同时添加多个礼包的情况，所以发放礼包只能按照

添加礼包，同步礼包到游戏，添加礼包，同步礼包到游戏，添加礼包，同步礼包到游戏

这个步骤来

否则，  这些新添加的不同礼包都会被按照同一个礼包来看待， 就算玩家分别拿到不同礼包的礼包码，  也只能领取一次。

这显然是个bug， 虽然按照第二种方法的步骤操作能得到正确的结果， 但是这即不符合人的直觉，我也没有在说明文档里注明这一点， 甚至刚开始的时候连我自己都不知道要通过这么繁琐的操作才能得到正确的结果，那我又凭什么要求系统的用户去这么做呢。

当我发现这个问题时，脊背上感受到一阵凉意，因为这个功能已经发布到线上使用，假如运营的同事一次性同时发布多个礼包，那这个bug会波及到很多玩家，直接影响游戏的口碑。要是bug真被触发，那就是运营事故，而且这个锅肯定是我的， 甩也甩不掉。

我心怀揣揣的把这个问题和游戏运营的同事说明，然后表示要修复这个bug， 然而他们的回应却是：“原来是个bug啊！ 我们还以为是你开发的功能呢，这个bug挺好用的，我们需要它”

震惊，我百思不得其解，在平常bug可是他们最痛恨的东西。

原来， 他们发放礼包的时候有一种需求，同时发放两个礼包， 两个礼包的道具虽然不同， 但是价值确实相似的， 他们只允许一个玩家只能领取两个礼包中的其中一个， 也就是说就算玩家分别拿到这两个礼包的礼包码，  兑换的话也只能兑换其中一个。

歪打正着， 这个bug不折不扣满足运营同事的特殊的需求。

把 bug开发成feature，我内心隐隐有种自豪感，然而这个feature 却是个定时炸弹，一旦有不知道底细的新同学使用这个功能， 那这个bug还是一个bug，而且杀伤力巨大。

所以， 问题来了， 这个bug到底要不要修呢， 纠结。