直到6一个月2号下午12时00，华为长达一个月的德州扑克锦标赛落下帷幕也被认为是。
我们的团队一直共同拥有3民，间。一个同学（吴）负责算法设计，一个同学（宋）负责分析消息，而我负责的实现框架设计和详细的决策算法。离5报名早年1月开始，要设置环境，设计框架，任务分工，以及各个模块代码的编写。从我个人的感觉来看，整个过程能够说是一个比較艰辛的历程。
德州扑克是一种棋牌类游戏。属于一种博弈过程，起先我对这个游戏没有不论什么的了解，最多的也仅仅是在影视题材里面见过，可是详细的游戏规则并不懂。而正是在这种条件下。我们參加了由华为举办的德州扑克大赛。比赛的形式，由华为官方提供服务端程序，这个服务端程序负责整个游戏的控制，而參赛的队伍则必须依照官方提供的通信协议，设计出自己的玩家程序。实现和server的对接，并和其它玩家进行博弈游戏，最大限度的获得存活场次和金币数量。
整个德州扑克的游戏分为四个阶段，包含了翻牌前（preflop）、翻牌（flop）、转牌（turn）、河牌（reiver），玩家在不同的阶段，依据自己的手牌信息和已知的公牌信息以及每个玩家的动作做出对自己最有利的动作以获得最后的奖池奖金，这里的动作包含了盖牌（fold）、加注（raise）、跟注（call）、让牌（check）、全押（all In），在每个阶段里面，仅仅有当全部的玩家投入的金额相等，或者全押，才会进入下一个阶段。而假设是弃牌的玩家。则放弃最后的奖池奖金，不參与后面的喊注。最后游戏的输赢是仅仅剩一个玩家或者在场的玩家的两张手牌和5张公牌组合出最大的牌型的玩家平分最后的奖池奖金。
依据官方提供的通信协议手冊，client能够将整个流程进行例如以下划分：
client先通过initialize和server建立连接，并注冊，然后调用recevMsg開始接收消息。解析消息，假设接收到了游戏结束game-over的报文，则调用destroy断开连接释放资源，整个流程结束。否则依据接收到的报文，解析里面的信息。然后依据须要调用Update更新游戏和玩家的状态。假设server要求client做出决策动作，则调用makeDecision依据当前收集的信息进行决策。然后把决策动作交由sendMsg返回给server，等待server的下一条报文信息，整个client游戏如此不断循环，直到游戏结束。
依据流程图，能够获得用例图：
依据例子用图，进一步分析。能够得到整个系统框架所需的类图，当然这个仅仅是初期的一个系统框架。粒度还是比較粗，这个仅仅是为了便于分工合作，提前设计好借口。后期还是依据不同的须要进行了部分的调整，初期设计的类图例如以下：
在设计中，依据用例图对模块功能进行了划分并封装。最后得到了上图的几个类。因为设计初期，我们还不能确认在决策算法中须要什么数据信息，所以，在Status类中仅仅是保留了接口和引用关系，里面详细的成员变量和函数则须要和详细的实现需求结合然后加以扩充，Action类的情况也是类似的。
这里的设计须要注意的是，为了使整个系统的各个模块部分有一个比較好的解耦效果，採用了设计模式中的策略模式，将决策模块提取出来。然后在主类中保留了接口，以便后期採用不同的决策算法进行替代，而不须要去修改其它模块。
在这次的合作中，我们採用的是敏捷开发的团队合作方式。整个合作过程。我们的文档部分仅仅有一些必要的框架文档和算法说明，剩余的部分还是以交流居多。整个过程中，团队交流次数3-4次左右，这种交流每次都要持续一个晚上的时间，大概3个小时左右，而成员之间的合作交流在4-5次左右。每次时间也都是2-3个小时。也就是说，在这次的合作过程中，我们强调的是沟通和效率，通过文档来记录交流一些基本信息，对于繁杂说明，我们选择了面对面交流方式，然后辅以必要的文档来提高共同效率。
敏捷开发出了注重沟通之外，还须要强调团队的个人能力，在我们的团队中，每一个人都明白分工，这个得益于一開始的框架模块划分，当中，具有较好的数学功底的同学负责资料的收集和算法的设计。剩余的两个。则一个负责消息模块的解析，一个负责框架的搭建和算法的编码实现。每一个人都各司其职。
此外。敏捷开发还注重阶段性成果的实现，在这个过程中，我们团队先从环境的搭建，然后是框架的设计。再是每个模块的实现，在每个阶段都一定的成果进度的安排和实现，然后在上一个阶段成果的基础上进入下一个阶段。尽管如此，但仍然存在一些问题与不足：
1、我们在整个团队项目中。没有使用代码管理软件，这是一个潜在的弊端。因为没有使用代码管理软件的经验以及对应的条件。导致我们最后在进行代码整合的时候出现了一些滞后的情况，还有一个同学在进行代码调试的时候。在进行交流才发现，他使用的代码并非我提供的最新版本号，这是我们遇到的一个代码统一问题。尽管那同学后来自己建立了SVNserver，可是因为机器性能不足。以及IP问题，后来没能用起来，这个是不足之处。
2、因为没有团队合作的经验，在编写代码的时候。没有注重代码的排版以及代码凝视说明。在帮助对方调试代码的时候。发现差点儿没有什么凝视，对于类的成员函数或者是结构体的成员都没有必要的说明。这个对于阅读代码的人来说是一个非常痛苦的，而对于函数接口的说明更是缺乏必要的功能说明，以及输入參数以及返回值的说明。这个给阅读和理解程序的人来说造成了非常大的障碍。对于团队的合作效率来说是一个不小的弊端。
3、在拿到对方的代码的时候。没有大致浏览对方的代码，对别写的代码没有一个总体的把握，使得没有可以使用别人提供好的一些接口，而是自起炉灶，这对于时间上的耗费以及潜在的bug的产生都是有相当大的代价，这在一定程度也使得项目的进展滞后。
4、在项目开发过程中。除了必要的沟通之外。对于一些重要的任务的分配应该有一些对应的反馈机制，在我们的开发过程中，就出现了这样一个严重的问题，在我的算法设计部分里面。须要一些消息解析过程中提供必要的參数信息，因为我在编写算法模块的过程，我不清楚还有一个同学的消息解析的情况，因此我仅仅有预留必要的变量，然后由消息解析的同学来负责补充，对于这个任务，我当时在群里嘱咐过后。对方也给予确认答复。
然而，问题就在于，我没有在后期对这个任务的分配进行完毕度的确认，使得我们在临近截止日期才发现最后这一块该同学并没有完毕。使得我们到了最后一刻还在编写代码，调试bug，以至于没有预留出比較充分的时间来測试程序的情况。
5、在软件project里面一直强调的是。在开发过程。唯一不变的是需求是不断改变的。是的，在我们开发过程中，算法的更新也是一而再。再而三的发生。直到最后临近截止时间了，负责算法的同学还提出求改算法模块的要求，对于他的这个要求。一个比較稳妥的做法就是先让该同学把改动后的版本号完整描写叙述出来，然后再结合改动的难度以及剩余同意时间所能做的改动考虑是否进行最后的更新或者调整。
这样的情况下的更新调整对于负责编码的同学来说是一个相当大的挑战，一个是要在有限的时间里面高速做出响应。还有保证最后调整的代码不会出现严重的bug问题。网络上有个段子。描写叙述的就是这个现象。说一个产品经理被程序猿打是由于到了最后还要改动需求。
这次我遇到的情况也差点儿相同是如此，所以怎样非常好地应对需求变化是一个比較值得思考的问题。
因为以上几个不足，使得我们最后用来測试的时间差点儿没有，我们仅仅能提交能执行的代码完毕比赛。最后的结果怎样应该都是能够接受的。
结果也在6月5号出来了，非常可惜。这次的成绩不佳。
比赛的大概过程我看了一下。总体来分析的话。第一轮，我们第一局进展非常顺利。拿到了第一名的成绩，可是后面两场都由于超时次数过多被踢出去。可是勉强进了前4，进入了下一轮。可是到了第二轮之后。非常幸运的是。没有出现超时（0.5S给出答复消息）掉线的情况，当中，第一局，一開始的情况还不错，可是到了363局的时候，出现了我们手拿9对子，和别人的A对子加注厮杀，随后allIn，就挂了。这个有点可惜了。
而第二局的话，一開始的进展就不太顺利，拿了不怎么样的手牌也和对手叫板，而其它牌手都相当保守，弃牌居多，在这一局里面，我们到了第9局就挂了。第三局的话，我们排在第4。应该说是正常发挥。一開始我们是率先的。后来在256局就输了3K多。情况也是差点儿相同拿了KQ和别人的A对和K对叫板，然后接下来就開始处于劣势，到399我们就挂了。
我分析的情况大体上如此，最后的时间确实比較赶，赛前没有时间好好測測我们的程序，毕竟总体框架都搭建好了，剩下的就是算法的局部调整，因为没有多參加几次官方的PK来发现算法的潜在问题，这个还是比較遗憾的，只是大家都挺尽心尽力的。
通过对照赛结果和參赛过程的分析发现，对于超时问题，一个是能力上的不足，没有充分利用多线程，由于能力的不足所以做起来没有把握，因此操心出现多投入零产出的问题，另一个是团队合作上的进度问题。进度的滞后使得最后没有空余的时间做測试。没有可以最大程度发挥我们的算法模型，这是一个比較遗憾的事。在后面的学习过程。如果在竞争的过程中更注重的诸多问题。我希望下一次有一个显著的改善和收获。
版权声明：本文博主原创文章，博客，未经同意不得转载。