结对编程
第一次结对项目总结
-
结对项目总结要求：https://edu.cnblogs.com/campus/ustc/InnovatingLeadersClass/homework/2231
-
项目Github地址：
https://github.com/qiweizhen/golden_number_ai
黄金点游戏基本规则
N个玩家参与游戏，每个玩家给出两个(0 , 100)之间的有理数，每一轮将所有玩家所给出的数的总和求出平均数，将平均数乘以0.618得到黄金点，所给出的数与黄金点最近的玩家得到N分，所给出的数与黄金点最远的玩家得到-2分，比赛M轮后所得分数最高的玩家获胜。
由于如果每个人只能出一个数，则每个人操作空间很小，如果给出不正常的分数就基本意味着扣分。所以为了每个人可操作空间的增加，规则为每个人每轮给出两个数。如此一来，就可以一个数字捣乱影响他人，一个数字拿分。或者也可以两个数字采取不同的预测策略等等。具体细节可以查看黄金点要求
PSP表格时间记录
| PSP各个阶段 | 预估时间 | 实际记录 |
|---|---|---|
| 计划： 明确需求和其他因素，估计以下各个任务需要多长时间 | 30 | 20 |
| 开发 | 30 | 50 |
| 需求分析 | 300 | 240 |
| 生成设计文档 | 20 | 60 |
| 设计复审 | 10 | 2 |
| 代码规范 | 5 | 5 |
| 具体设计 | 20 | 5 |
| 具体编码 | 120 | 120 |
| 代码复审 | 20 | 5（所以导致第一局中出现bug） |
| 测试 | 120 | 60 （数据集的黄金点很小（往往小于1）导致没有看出来数据是错的） |
| 总共花费时间 | 625 | 452 |
实际上，结对编程之后发现时间的花费和一个人写代码差很多。一个人的话，主要的时间会花费在写代码上。而两个人一起的花费时间则会在讨论上花费更多的时间。而且一个人敢于去尝试一些自认为有效的想法，尽管在测试集上结果不太好但是会想在比赛中尝试。两个人的话则会保守的多，担心坑到对方同学，这也就导致了很多版本代码的抛弃，而最终使用了最简化最保守的版本。
算法设计与实现
代码主要分为了三个版本。在代码库中各有对应。
第一个版本是宇飞写的深度强化学习代码，在尝试最初版本后发现会对训练集依赖太大过拟合，对于和训练集不同的波动范围的内容等情况适应性很差，在一开始给的数据集上无论训练哪一个在另外一个表现都非常差。所以可以解决的方式是比赛中训练。考虑到每回合时间后决定放弃优化和这个版本。可以考虑比赛中去学习，但是深度学习是不可用的。
第二个版本是发现了在平稳的时候捣乱数据可以极大的拉动黄金点的位置，从而可以在平稳的时候突然拿一个很大的数出来，虽然扣两分，但是把黄金点可以拉高2左右，此时可以比较有把握的拿到十几分。所以这一个版本的代码主要在判断当前是否平稳或者当前的数很小，虽然波动超过比例但是仍然可以影响很大，拉高很多。
第三个版本是考虑到大家看了原始数据之后都会想到捣乱可以很有效的拿到分数，那么平稳就不再可能。此时可以预测别人此回合是否捣乱，以及捣乱程度来做辅助。采用了大数定律和概率期望两种策略和不同的窗口大小作为待选方案，每次更新哪个策略的效果最好保存在文件中，并采取最好的策略。
函数说明:
| 函数名称 | 功能 |
|---|---|
is_smooth |
通过对历史4轮数据的分析判断当前状态是不是平稳，是否进行捣乱 |
small_enough |
通过对历史4轮数据的分析判断当前的黄金点是不是小于预设的值， |
pre_disturb_majority_rule |
采用大数定律预测每个人下一轮扰动增加数值，并把预测结果保存在npy文件中，在下一轮得到上一轮黄金点后找到最接近黄金点的窗口大小与概率期望比较，并选择最佳策略 |
pre_disturb_majority_rule |
采用概率期望预测每个人下一轮扰动增加数值，并把预测结果保存在npy文件中，在下一轮得到上一轮黄金点后找到最接近黄金点的窗口大小与大数定律比较，并选择最佳策略 |
Design by Contract
契约式设计就是按照某种规定对一些数据等做出约定,如果超出约定,程序将不再运行,例如要求输入的参数必须满足某种条件。因为输入是规整的输入，而且我们数据的保存和读取都是使用numpy的save和load函数，没有想到出现约定之外数据的可能。
代码规范及异常处理
代码长度百行以内，代码规范就是常规的python排版和命名方式，把功能尽量拿出来函数化。对于计算的结果，则进行了值域判断，不会输出非法值。
结对编程
结对过程： 一开始的思路是每个人都拿出来一个最简单的bot，创造一个动态的比赛环境，因为一开始就意识到了静态的数据无法得到我们参与结果的反馈，效果比动态差很多。其次是可以再这个过程中，每个人尽快熟悉起来代码，最快地参与讨论。
因为我们对强化学习并不了解，所以一开始我们确定了几个粗略的时间结点，比如一天的时间来熟悉强化学习的内容，之后交流讨论各自的了解，进一步确定算法步骤等。在确定算法步骤后，我们采取合作编程的方式编写了函数的框架和功能划分，之后采取分工的方式进行了对函数的完善和调试。
结对编程方式： 各干各 -> 有想法后开始讨论定方向 -> 分工完成
结对编程优点和缺点:
优点：可以快速的进行思维展开，对于问题的认识很容易有进一步的想法。可以在给互相讲解自己部分代码的过程中发现问题，加深理解。互相检查代码比debug自己的代码效率更高。
缺点：虽然可以产生新的想法，但是一起做效率会变低。不敢尝试新的难的算法，做法会变的相对保守，因为会担心坑到队友。
其他收获
结对编程可以在交流中拓展思路，但是前提是每个成员都要对项目有一定程度的认识。所以分工一开始分工各干各是比较合适的。但是最终结对过程中也发现了一开始没有意识到的结对编程该注意的地方，比如各干各 -> 有想法后开始讨论定方向 -> 分工完成后缺少再碰头商量成品和互相测试对方代码的内容。或者可以每个人完成自己的分工后通过给组员讲自己的代码来完成。自己测试自己的代码还是很容易出问题的，比如盲目自信等等。这也导致了我们第一版的代码bug导致分数非常低，而且在测试中，因为本来的测试数据很多都在零点几附近了，少了百分之几十根本看不出来。这是在以后需要注意的地方。
