作业要求：

源码地址：

黄金点游戏简单介绍

假设有M个人参与黄金点游戏，每轮游戏每个人提两个(0, 100)间的有理数，共2M个数，求这2M个数的平均数再将这个平均数乘以0.618得到这一轮的黄金点，提出离黄金点最近的数的人得2M分（同样近的人一起得分），离黄金点最远的人扣两分。

在本次实验中，我们需要写一个bot来在每轮游戏中自动提出两个数，每次游戏前，bot能拿到之前所有轮次游戏的每个人提的两个数和黄金点，每场游戏共进行400轮，共有上半场和下半场两场游戏，累计得分最高的bot获胜。

我们的策略介绍

我们放弃了预测每一个对手的输出和使用强化学习等复杂算法的方案。相反，我们使用简单的统计策略，利用前n局的黄金点的信息，对当前黄金点进行预测。我们采用一个队列，对前n局的黄金点信息进行统计，并且根据一定的划分和更新策略，我们可以得到m(\(m \leq n\))个黄金点，然后我们根据队列中概率最大的两个黄金点进行输出。

PSP表格记录预估时间

我们的项目开始时，并没有考虑利用PSP表格预估时间，在后面的实验中，我们会改善此方面。

接口设计

由于我们的bot仅仅只需要一个前n个黄金点的统计队列，以及待选黄金点的更新列表，所以我们预打算一个函数实现所有功能，根据当前history信息，返回插入和更新后的待预测黄金点列表和近50轮的统计队列。主函数根据返回的信息进行输出。

接口实现

我们的程序功能十分简单，只有两个函数，没有class，所以并不需要流程图的表示。另外在设计的过程中，我们的算法考虑到了存在少数人捣乱的情况，可以去预测两个黄金点的极限值。另外对于大家更改策略的行为，我们的队列也能够很快的得以适应。

UML图

仅有2个函数，没有类，没有实体，所有并不需要UML图的表示。

Design by Contract

• DbC的优缺点
  • 优点在于代码调试很简单，每一个过程的行为意图都定义的非常清楚，且不能够被违反。另外因为关于代码实现的契约已经文档化，所有有利于代码重用。
  • 缺点在于实现代码之前，会花费很大的时间和精力，去商讨代码契约，规则较强，可能后期根据实际情况也需要修改。
• 我们方法中的体现
  我们在这次编程的任务中，由于任务比较简单，关于接口的交流较少，所以并没有采用这种设计方式。

结对共识

我们分工合作，在编程之前就已经互相商量了应该传入的参数和返回的结果，采用简单的注释，我们便达到了共识。在编程中没有遇到异常。

UI模块

我们并没有UI模块，所以并没有UI模块的设计和其他模块之间的对接部分。

结对过程

我们的结对过程非常的愉快，在合作中我们互相学习，共同的进步。

下面是我们正在讨论的过程。。。

结对小伙伴

我们在结对过程中，采取的是驾驶员和领航员灵活的合作方式。通过指导监督和执行的交替合作，我们获得了更好的合作体验。

• 结对编程的优缺点
  • 结对编程有助于双方互相学习对方的优点，为合作提供更好的代码质量和设计质量。
  • 合作双方有更大的积极性，能够参与到合作中。
  • 有的时候，会出现双方互相甩锅的情况，会使得合作的效率大大降低。
• 合作伙伴的评价
  • 我的合作伙伴Kai Hu，是一个非常积极聪明的小伙伴。在讨论阶段，能够提出非常creative的idea，在代码实现时，也能够首先承担起coding的责任，且能够在整个过程中不断的提出非常有意思的改进的意见，所以没有缺点:)

实际花费时间

这个在我们的实际过程中并没有记录，所以无法进行对比。

其他收获

在这次的比赛中，我们的方法比较简单，主要是我们担心复杂的算法会花费我们较大的时间精力，最后结果也不是很好。所以了，一分耕耘一分收获，没有付出，就没有回报。在以后的作业中，我们会认真的对待。