第二次结对编程作业
分工##
- 林少惠:原型开发、前端开发
- 宋奕:后端接口开发，AI算法，后端部署
PSP表格##
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 900 | 1120 |
| Estimate | 估计这个任务需要多少时间 | 1020 | 1320 |
| Development | 开发 | 900 | 880 |
| Analysis | 需求分析(包括学习新技术) | 200 | 210 |
| Design Spec | 生成设计文档 | 25 | 30 |
| Design Review | 设计复审 | 5 | 15 |
| Coding Standard | 代码规范(为开发制定合适的规范) | 20 | 11 |
| Design | 具体设计 | 15 | 70 |
| Coding | 具体编码 | 450 | 600 |
| Code Review | 代码复审 | 15 | 50 |
| Test | 测试(自我测试,修改,提交修改) | 160 | 180 |
| Reporting | 报告 | 90 | 60 |
| Test Report | 测试报告 | 55 | 15 |
| Size Measurement | 计算工作量 | 5 | 8 |
| Postmortem & Process Improvement Plan | 事后总结并提出过程改进计划 | 20 | 45 |
| 合计 | 3880 | 3734 |
解题思路描述与设计实现说明##
- 该项目只调用助教提供的接口，和后端开发人员所写的接口
- 算法的关键就是对于牌型的判断，
判断牌的花色->做整体判断是否有相同的牌(分情况讨论四张、三张、两张)->一组一组判断特殊牌型->分配权重->出牌
关键代码解释
一个近似遍历的算法，我认为每个判断都很关键就放出部分判断特殊牌型的算法
性能分析与改进##
- 描述改进思路
我对我的输入输出进行了改进，原本是便历字符串，现在是写了一个dto，这样传输来说会快点。本来对于牌型的判断可以合并能够更加智能，但是由于面向功能编程所以未做优化。 - 展示性能分析图和程序中消耗最大的函数
消耗最大的函数就是我所写的change函数，这个就是我的判读出牌规则的函数
单元测试##
如图为我的测试代码
我通过改变传入的牌来测试输出是否正确，我所测试的测试数据，尽量测试特殊牌型，同花和顺子同时存在的时候如何取舍，还有某些偏僻的特殊牌型如何取舍。
贴出Github的代码签入记录##
遇到的代码模块异常或结对困难及解决方法##
- 问题描述
在前后端交接的时候遇到跨域问题，已知解法是加一段config就可以解决，问过另外一对，他们并没有解决跨域问题，却可以正常连接 - 做过哪些尝试
在服务器上搭载docker，解决不了跨域，尝试是不是前端用Python写避免了跨域，显然不行，最后猜测是腾讯云的服务器避免了跨域，和代码没关系，阿里云8行 - 是否解决
跨域问题解决，但是忽略跨域问题未解决，问过在企业上班的学长也不懂，他只对那个Python前端喊了666 - 有何收获
解决问题的过程十分痛苦，但是制造特殊情况我们是认真的！
评价你的队友##
- 值得学习的的地方
少惠真的也太努力了，有责任心，能熬夜吃苦，我只会喊666 - 需要改进的的地方
姐姐，拿了这么多奖可以歇歇了，注意劳逸结合
学习进度条##
| 周数 | 新增代码（行） | 累计代码（行） | 本周学习耗时(小时) | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 0 | 0 | 2 | 2 | 更加深入的了解以美工的思维思考问题 |
| 2 | 400 | 400 | 9 | 9 | 对于后端接口的理解尤其是调用第三方接口 |
| 3 | 800 | 1200 | 5 | 5 | 对于前后端交互的理解，ajax深入 |
| 4 | 500 | 1700 | 4 | 4 | 服务器对于docker部署 |
