第二次结对编程作业
具体分工
队友负责ui的设计，我负责 后端ai的实现和 网络接口的衔接。
PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 60 | 60 |
| Estimate | 估计这个任务需要多少时间 | 1000 | 2000 |
| Development | 开发 | 300 | 480 |
| Analysis | 需求分析 (包括学习新技术) | 120 | 180 |
| Design Spec | 生成设计文档 | 30 | 40 |
| Design Review | 设计复审 | 10 | 15 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 30 | 30 |
| Design | 具体设计 | 240 | 300 |
| Coding | 具体编码 | 1000 | 1200 |
| Code Review | 代码复审 | 180 | 240 |
| Test | 测试（自我测试，修改代码，提交修改） | 300 | 360 |
| Reporting | 报告 | 20 | 30 |
| Test Repor | 测试报告 | 30 | 60 |
| Size Measurement | 计算工作量 | 30 | 60 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 30 |
| ㅤ | 合计 | 2300 | 3100 |
解题思路
刚拿到题目就想到了 可以直接暴力枚举所有情况，因为总情况的数量是很少的 仅有 7w多种， 对于每种情况赋一个大致的估值进行排序， 粗略的筛掉大部分的情况， 留下小部分的情况， 对于小部分情况再进行细致的筛选，
网络接口的使用
用py写(偷)的网络接口
类图
| 函数名 | 函数作用 |
|---|---|
| ans | 输出答案 |
| check | 判断该牌型是否合法，合法就丢入粗筛数组中 |
| dfs | 深度优先搜索 枚举所有情况 |
| doit | 运行算法， 记录答案 |
| fc_to_number | 花色hash |
| num_to_number | 大小hash |
| number_to_fc | 花色逆hash |
| number_to_num | 大小逆hash |
| pk | 细筛进行大小比较 |
算法的关键与关键实现部分流程图
我觉得关键的部分是对于牌型的分析， 枚举部分过于简单个人认为并不关键。
有价值的代码片段
枚举部分
dfs算法，将牌型转成二进制位，记录已选的牌型和未选的牌型。
性能分析
从中可以看出来， 时间占用最多的是 枚举算法之后 计算权值的时间， 于是我优化了计算权值的方法， 减少了枚举的次数， 进行了一部分剪枝之后大幅度优化了时间。
单元测试
测试思路
先测试 是否正确的枚举了所有情况， 然后测试分值函数是否正确， 之后测试 比较函数是否正确， 最后测试 答案是否优秀。
commit记录
遇到的代码模块异常或结对困难及解决方法
问题描述
网络接口用c++实现很复杂
做过哪些尝试
尝试用c++解决，但是发现太麻烦了， 最后选择py
是否解决
已解决
有何收获
学会了不能一直依赖C++， 以及学习了python对网络接口的调用。
评价队友
值得学习的地方
队友做了很多我不会的事情，ui图片的设计方面值得我好好学习。
值得改进的地方
代码方面可能写的比较少，但是大部分问题还是解决的非常好。
学习进度条
学习进度条
| 第一周 | 新增代码（行） | 累计代码（行） | 本周学习耗时（小时） | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 0 | 0 | 6 | 6 | 对墨刀有了初步的了解 |
| 2 | 0 | 0 | 15 | 21 | 临时恶补作业所需知识 |
| 3 | 1200 | 1200 | 20 | 41 | 设计算法和UI |
| 4 | 300 | 1500 | 11 | 52 | 对接以及各种调试 |
