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、评价你的队友
致大锋哥:
值得学习的地方
那个UI界面是真的不错,我锋哥的审美找图做前端还是值得舔一舔的。然后虽然平时嘴边一直抱怨着,但是还是很积极的去完成自己的任务。并且是不带拖沓,行动能力贼高。自我感觉自己就比较随性,可能会比较拖
需要改进的地方
暂时没有(自私一些说的话,对同伴多一些耐心嘻嘻嘻)
11、学习进度条
||||||||||||||||||||||
|:--😐:--😐:--😐:--😐:--😐:--😐
|第N周|新增代码(行)|累计代码(行)|本周学习耗时(小时)|累计学习耗时(小时)|重要成长|
|1|0|0|15|15|学习墨刀的使用和福建十三水的具体规则|
|2|1292|1292|50|50|学习python库tkiner的使用;|