七月到八月间，花了三周时间，把公司的永州扯胡子的服务器端重构了一遍。最开始是不想重构的，但是原代码业务复杂，经手过三四个程序猿，代码已经无法维护。经常是改了这个bug又出现了其他几个新bug，对于优先级最高的几个无法胡牌的bug，追溯了一下代码，感觉是算法设计本身的缺陷所致。于是开始了重新改写，开始估计得过于乐观，导致了两次延期，历经三周，加班无数，终于搞定。从上周五上线到今天，运行情况还算良好，尚未收到bug反馈。
虽然是顺利通过了测试和线上运行稳定，但是代码中还是有几个已经发现的并未解决的问题的。
1.永州扯胡子因为又王牌的存在，会出现“王钓”“王闯”的特殊胡牌方式。这一点，是早期设计没有考虑周全的。当前的代码实现是基于摸到牌组成一套牌，然后进行拆解来判定是否能胡，对于“王钓”和“王闯”采取的其实是事后判定。这种事后判定，经过几版补丁也基本能把所有情况概括在内。但是因为本身是不契合真实逻辑的，所以拓展性不高。对于后续可能出现的四王扯胡子，只能靠更多的补丁来实现。（因为项目时间紧迫，对于这块的设计缺陷并没有做修正。）这里正确的思路应该是修改一下胡牌检测算法，让其可以支持对于“缺子”牌型的识别，对于满足王钓、王闯基本要求的牌组，先启用这种“缺子”识别来判定是否为王钓王闯。
2.重写过程中，对于最后的胡牌牌型的显示支持是有问题的。出现这个问题的原因是当前设计采用的基于牌值检测的方式与原实现不一样，而最后胡牌牌型的前端是基于原实现的，不能很好的兼容现在的设计。这里最佳的方案是让前端来兼容后台（实现很简单），而非让后台来兼容前端。最后三四天基本一直在改这个问题带来的bug，后续有时间思考时才想通这一点，但那个时候反馈的bug已经被“补丁”修改了，所以没有修复该问题的实现旧直接上线了。而实际，这里应该是存在隐患的。（但是影响不大，只是把“胡”字显示错位置）。
3.存在较大的性能优化空间。因为胡牌牌组识别采取的是遍历的方式，而整个打牌过程又存在大量的胡牌检测，这里是存在较大的性能优化空间的。最后上线前，检测胡牌检测单次执行的耗时在1毫秒以内，在当前用户量级下，该处也不会有问题，上线压迫，所以没有进行修改。这里一个最有效的优化方式就是做个定量的临时缓存（因为跑胡子的特点是不会进手牌，所以会存在大量的重复检测）
几个以后做游戏开发时值得思考的点是：
1.类似于这次算法问题核心的改进点：牌值和牌ID的选择的问题。原检测是基于id检测，所以对于王牌几乎无法处理。一个简易的思路会是把王牌变牌后进行原逻辑拆解，但是这种方式会带来计算量的几何倍数增长，性能方面出现严重问题。用牌值处理也会碰到问题（虽然在这个项目中不明显），就是牌值处理的过程可能会丢掉特定id的对应关系，如果处理结束后需要追溯哪个id是哪个牌值，可能就只能靠其他方式去找对应关系，会很麻烦。（这里在我这个项目中体现就是上述的2。花费了大量时间但是处理效果堪忧，因为本是设计源头带来的）。这里值得思考的点是，哪些场景会需要id这种唯一性的对应，而哪些过程又是可以忽略这种唯一性的，对于有些部分需要唯一性对应而有些处理又不需要唯一性的处理，但是处理完毕后又需要找回唯一性对应的过程应该怎么应对。
2.前后端状态同步的问题。有些操作是在前端进行，有些操作是在后台进行，有些操作是前端通知后台进行的，整体过程中又可能出现掉线、重连等各种情况。设计初期就应该考虑好采取哪种模式。（这个问题在棋牌中比较简单，因为棋牌的内容和操作模式很简易）。
3.版本规划的问题。这一点也应该是在前期就需要考虑好的。如果存在多个游戏版本或者游戏对于一套代码有依赖，最好是前期就规划好怎么做方便维护（这里先不考虑代码安全的问题）。涉及规划时也可以把代码按照可能的修改频率区分，因为高频修改的代码在团队开发过程中容易带来冲突和产生覆盖，可能增加维护的时间成本。
暂时就这一些吧。架构上的可说点比较多，那个后续再发文。
网友评论