第二次结对编程作业

1、相关链接

031702342黄智锋
博客链接：https://www.cnblogs.com/hzf---2000/p/11749907.html
Github链接：https://github.com/hzf-hhh/fujian13

031702342黄彬煌
博客链接：https://www.cnblogs.com/yellow-2018/p/11748880.html
Github链接：https://github.com/yaoxuan2018/shisanshui

2、具体分工

黄智锋：负责UI前端和网络接口的设计，部分博客的撰写；
黄彬煌：负责出牌算法的设计，部分博客的撰写。

3、给出PSP表格（2分）

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	300	300
· Estimate	· 估计这个任务需要多少时间	52	60
Development	开发	5100	6800
· Analysis	· 需求分析 (包括学习新技术)	230	350
· Design Spec	· 生成设计文档	140	160
· Design Review	· 设计复审	30	50
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	200	400
· Design	· 具体设计	400	600
· Coding	· 具体编码	2000	3000
· Code Review	· 代码复审	200	300
· Test	· 测试（自我测试，修改代码，提交修改）	600	720
Reporting	报告	30	50
· Test Repor	· 测试报告	30	40
· Size Measurement	· 计算工作量	20	30
· Postmortem & Process Improvement Plan	· 事后总结, 并提出过程改进计划	130	230
	· 合计	9462	13090

4、解题思路描述与设计实现说明

（1）网络接口的使用

登陆接口

排行榜接口(历史战局\详情用同样的做法提取出所需)

发牌接口：

出牌接口：

历史战局接口（treeview组件插入）

历史战局详情（treeview组件插入）

（2）代码组织与内部实现设计（类图）

（3）说明算法的关键与关键实现部分流程图

该算法首先是对输入得到的字符串进行分割，然后存入列表中。再用到itertools模块里面的combinations组合函数从列表中的13个元素任取五个，然后再从剩下的八个中再取5个。最终分成三份。再对这三份进行牌的类型分析，得到相应的胜率点，中间再对三墩进行分析，是否符合底墩大于中墩大于头墩的原则。最后比较胜率点，将胜率点总和高的三墩牌型保存下来。最后输出。整个算法来看的话，关键点，就是胜率点的编写了，确保相对准确。

流程图：

5、关键代码解释

第一张图是将13张牌组合成数量为5 5 3类型的牌堆，为什么说它重要呢？是因为我自己本来的算法是从底墩向上一层一层判牌型，再结合估计能够赢取更多水的概率，最终确定所要输出的牌型。但是在判牌型这一关自己所写的代码量巨大，并且不保证不会出现问题。最后索性暴力分配再去做判断，缺乏一些艺术技巧吧。但是，真的在用十几行代码做完上千行代码需要做的事后，是真的会感动到痛哭流涕，真救命。
第二张图是后面做完算法，在和别人比拼运气算法时出现的问题，经常超时。就好像四剑客PK，其他三人已经收刀了，另一个还没把刀拔出来，已经不是多尬的问题了，已经上升成送了。。后来，排除一堆问题后，只剩下算法了。但是算法又挑不出刺来了，我甚至还对一些情况进行一个if的特判运行，然后continue掉，但实在想不明白为啥还是运行了那么久的时间。最后是灵光一闪，改掉numpy模块的zeros函数，一运行，瞬间少了一半的出牌时间。那一瞬间，真的是。。（原谅我的词语匮乏，太久没课外阅读和做语文卷子了~）

6、展示性能分析图和程序中消耗最大的函数（1分）

性能分析图:

消耗最大的函数:

7、单元测试（5分）

部分代码（主要是比较和输出）：

测试函数：

https://github.com/yaoxuan2018/shisanshui/blob/master/%E7%AE%97%E6%B3%95

构造函数理由

实际上是测了好几组，但在这里就展示出上面的两个比较有代表性的数据。一种是随机的，另一种是特殊牌型。之所以用到特殊牌型是因为实际上在写AI算法时没有分类，但是特殊牌型又比一般牌型来的大，如果能够按最优的来出，那其余也差不多了。随机的话，大家应该都懂。就看他出牌合不合理，会不会出现类似把炸弹拆了做对子一团糟的牌。

8、贴出Github的代码签入记录（1分）

9、遇到的代码模块异常或结对困难及解决方法（8分）

编写前端，接口遇到的困难，尝试：

编写前端是选择里面的图形化界面tkiner库，由于刚开始对这个库不熟悉，还一度想转战pyqt，了解一下打扰了，更难，最后还是继续研究tkiner,甚至花了好久去设计布局(起初不知道有place函数，网上的狗屎教程)，最后还利用了墨刀来设计界面（有带坐标，超级方便），布局之后就是设计界面之间的交互，通过按钮来实现，花了很久时间搞清楚按钮函数里的参数（蛇皮self参数）。

问题是否解决：

问题最后均解决

有何收获：

掌握了一些编写前端的小技巧，其实前端跟原型设计相同，只是按钮功能需要自己设计，个人还是很喜欢前端这一方面，看到好看的界面交互，心里的成就感还是蛮大的。

算法困难：

一开始没认真阅读所要写的具体算法，想当然的认为是写判牌算法（难道不是要写一个小软件大家一起玩？？怎么就变成写个小出牌机了。。）导致白写了几百行代码以及浪费了一些时间还有心态又崩了，自作孽，也是没办法。后来，欣喜的发现后，继续了苦逼的打码过程。期间，听取了前辈的建议，从底墩向上一层一层判牌型，并且估计获胜的概率，以此作为唯一标准。但是在实现的时候，由于是类似于深度优先搜索算法一样需要保存现场，以便后续的搜索，导致变量设置有些多，加上需要考虑的情况比较多（单就底墩如果能是同花顺的，中墩头墩结合起来就有36种）时间又比较紧迫，最重要的菜是原罪，实在是太难了。后来解决后，又遇到代码超时的情况。numpy的内置函数还真是偷时间啊。。

问题是否解决：

能够安详的写着这些蛇皮话，这么聪明的读者一定懂吧，嘿嘿（是的，解决了。请原谅我的冒犯~~）

有何收获：

首先是当分类情况超出自己的能力的时候，可以尝试暴力解决。许多时候，暴力能省去许多烦恼。其次是，对于想当然这个缺点，实在是需要一直去注意的，但是又不懂得怎么去解决，有点麻烦。最后是，不要一直图取便利。有时候，别人写的内置函数模板，可能包含了许多自己不知道细节，而这些细节对于自己的需求并无关紧要？这样想，那就不对嘞。他还会占用你的时间空间，让你快乐的送分。无用功，有时候还是很麻烦的。

10、评价你的队友

黄彬煌:

值得学习的地方

算法代码能力很OK，分析问题的能力也不错。
需要改进的地方
做事有点拖沓。。。。。。

11、学习进度条

||||||||||||||||||||||
|:--😐:--😐:--😐:--😐:--😐:--😐
|第N周|新增代码（行）|累计代码（行）|本周学习耗时(小时)|累计学习耗时（小时）|重要成长|
|1|0|0|15|15|学习墨刀的使用和福建十三水的具体规则|
|2|1292|1292|50|50|学习python库tkiner的使用；|