第二周作业 - 黄金点结对编程总结

第一次结对编程的项目是黄金点游戏的比赛，我们从讨论到实现只用了大约不到一天的时间，而且全程都是两人一起编程，全部代码都在get_numbers.py一个文件中，因此没有使用 github 来管理代码。

PSP 表格

我觉得由于这次项目的结构简单，代码量也不大， PSP 表格并不是很适用，但是，我还是给一个简单的 PSP 表格，因为我们事先也预估过项目所需的时间。

PSP 各个阶段	预估的时间
计划： 讨论我们的大致策略	2h
开发：实现我们的策略，给出最初版本 V1.0	2h
测试：测试V1.0， 并根据测试结果提出改进想法	1h
开发：实现V2.0	1h
测试：测试V2.0	1h

接口设计

我们的代码结构非常简单，基本没有涉及需要设计接口的部分，我们所有的数据都以 numpy进行传递。

算法实现和UML图

首先， UML 图并不适用于我们的项目，我们没有使用对象，只把一些很简单的基础功能放到函数中，并在主函数中调用这些基础的功能，下面介绍一下算法的实现：

首先，算法开始我们会从标准输入流读取比赛的历史数据 history， 并且判断这一轮是否需要捣乱操作：判断标准是最后两轮的黄金点的差值是否小于 GATE * 前 N 轮黄金点历史差值的平均。如果是，那么采取捣乱策略，反之就不采取捣乱策略。这里的 GATE 是一个固定的参数，我们调整为 0.3。

接下来，根据选择的策略返回我们输出的两个值。如果不采取捣乱策略，我们会以随机的方式输出两个值，但是，随机的范围并不是随便设定的，而是根据上一轮黄金点的值来判断的。如果采取捣乱策略，我们会提交一个较大的值 (>=80) 和另一个拟合值，较大值是所有超过80的历史数据中的最小值（防止自己扣分），拟合值是上一轮黄金点的值加上 Lambda * （较大值 - 上一轮黄金点），这里， Lambda 是一个动态调整的参数。

最后，算法会根据历史的反馈，来动态调整参数。一个需要调整的参数是捣乱策略时的 Lambda，如果发现在历史数据中，捣乱人数较多，导致我们算法的拟合值小于那一轮的黄金点，那么算法就会增加 Lambda ，反之，当拟合值比黄金点大太多时，算法就会减小 Lambda。另一个参数是不捣乱时，随机点的范围，如果检测到历史数据中捣乱的队伍较多，就会使得一个随机点的范围上调，反之就不做调整。

Design by contract

这个做法的思想是精确的限定接口和数据，保证程序执行和软件的质量。我们的代码中，各个函数的功能都非常明确，数据接口也很简单，因此函数的接口本身就已经十分精确。

程序代码和设计规范

程序的逻辑我们是事先讨论好的，代码的一些规范（比如变量命名，注释一类）会在结对编程的时候实时指出并改进。由于程序的比较简单，函数功能也很明确，除了一些很明显的异常处理（文件读取异常），没有发生其它异常的情况。

界面模块

我们的程序没有界面模块。

结对的过程和照片

我们在开始实现的前一天，讨论出了我们算法的大体思路。在实现的那一天，先按照原先的计划，很快实现出了第一个版本，然后经过测试，讨论，继续改进，实现了第二个版本。全程都是结对编程。（但是没有人给我们拍照）

合作方式，结对编程的优点和缺点

方式就是很传统的领航员+驾驶员的方式。

优点：效率很高，代码思路很清晰，在有一个人不知道怎么写的时候，另一个人能补充；有错误的地方也能指出；有代码写法可以优化的地方也可以及时优化。

缺点： 这个项目有点小，只能是结对编程的一次小体验，暂时没有发现什么缺点。

PSP 表格

PSP 各个阶段	实现的时间
计划： 讨论我们的大致策略	2h
开发：实现我们的策略，给出最初版本 V1.0	1.5h
测试：测试V1.0， 并根据测试结果提出改进想法	1h
开发：实现V2.0	1.5h
测试：测试V2.0	0.5h

基本上和预估的一致，第一个版本实现的较快，第二个版本实现时间稍长，总时间和预估差不多，一天不到就完成了。

其它收获

这是一个比赛，我们总分取得了第三名。我们的算法的确很简单，但是实际上策略还是十分有效的。算法的缺点也比较明显，一些参数的自动学习和调整非常依赖经验和数据，我们没有能够很好的掌握。

不过，我也切身体会到了结对编程的好处，效率非常高，对两个人的锻炼也很明显，结对编程是从自我监督到互相监督的一种转换，某种程度上依赖队友，同时又需要监督队友，需要更集中的精神，另一方面，结对也是与人沟通的过程，对表达自己的想法也是一种锻炼。