跑胡子程序开发记录（六）——几则逻辑BUG修复记

超过五千行的代码，而且是网络版的程序，而且需要服务端和客户端的交互的流程控制，而且面对的游戏规则复杂的跑胡子游戏，出现逻辑上的错误在所难免。
第一次把写好的程序让同事一起玩，也算是一起测试时，就出现了一个非常尴尬的情况：当他的手中的牌只剩下两张，而且是相同的牌，而且胡息数不够时，遇到了可以碰的情况，我同事因不太熟悉跑胡子的基本规则也就直接碰了，然后手中就没有牌了，不可能打出牌了。这在现实的游戏时，是不允许的。
像这种情况，虽然在现实中几乎不可能存在，但为了程序的健壮性考虑，必须要能正常应对这种情况。所以，为了修复这问题，我便在程序中加了一种逻辑：当玩家的手中的牌（不包括手中的坎）小于三张时，则不能吃，不能碰，直接返回进字代码为0（当然是可以胡牌的，胡牌代码由另外的程序逻辑负责），这样就避免了这种尴尬情况的出现。
后来程序在交给我哥玩的时候，又发现一个新的问题，如果手中除了坎，只剩一对时，自己再摸到这张牌可以胡牌时，却不出现胡牌的选择，我当时还怀疑那手牌是胡息数不够，因为我记得对于提、偎可以胡牌的操作是已经处理好了的，而且我也没有看到当时我哥的牌局，便没有认真考虑这个问题。
程序在不断的完善、试玩过程中，终于在某一次，在自己的电脑上重现了这个问题。可以偎胡的情况，没有胡牌的选择。看来我哥遇到的问题是非常肯定的存在的。
为了处理这个问题，追踪服务端程序和客户端程序对于提偎胡牌的处理代码，然后构造一局可以偎胡的发牌数据：取在手的牌，全是坎，接下来取的第一张牌，就是偎，然后要胡牌。然后在程序中设置断点，查看数据的变化情况。
最后终于发现，引起这个问题的原因，是在修复上面那个问题时的返回值，与提偎胡的判断逻辑出现了冲突。原有的对于提偎胡的判：必须满足进牌代码是提或偎的代码，且有胡牌的代码，界面上才会显示出胡牌选择。而修复上一BUG时，看似很好的解决了除坎外只剩两张牌不能吃不能碰只能胡的逻辑，但也忽略了可以偎的代码。虽然可以胡牌的判定是在另一处代码中，但它也不会包含是否可以偎的代码。所以综合的返回值，达不到可以提偎胡显示胡牌选择的条件。
这是典型的修复一个问题引发一个新的问题。如果之前没有修复上面第一个逻辑BUG，是不会出现第二个逻辑BUG的。
不管怎么样，只要问题的原因找到了，就有办法修复。为此，重新完善第一处逻辑修复时的代码，将0值的返回推后，如果除了坎之外还剩两张牌时还可以偎，及时返回偎字代码。
至此，算是修复了这个问题。
但我现在还是有一个疑惑，即使是现实的牌局中，如果某个人最后只有两张一样的牌，然后摸到了相同的这张牌，按规则必须要偎，但是如果就算是偎，胡息数还是不够，不能胡牌。那么，这个时候，他应该是偎，还是把这张牌扔掉。如果是偎，然后他必须再打出一张牌，但他会无牌可打。如果是不偎，则也不符合跑胡子的基本规则。咋整？
当然，这种情况在现实中出现的概率应该比买彩票中百万大奖的概率还要低。毕竟，正常打跑胡子的人，不可能把手中的牌放得只剩两张牌了还没挣够胡息数的。
所以，这种特殊情况，我在程序中就没打算很完美的考虑它了。
然后昨天又遇到一个新的问题。发牌完成，某个玩家已经有了两手提的牌，然后第一次轮到他打牌时他打了一张牌。按现实中的规则，他是不能打的，由下家直接取牌。
好吧，这个问题我之前确实还没有考虑。在现实中出现这种情况的概率，应该好比买彩票中个小奖吧。今天，该处理这个逻辑BUG了。