一、结对感想
1.结对在花的时间上小于一个人，原因是和队友一起讨论题目要求、制定方案可行性，远比一个人效率高。
2.在写程序的时候，首先领航员在一旁监督能极大的减少手误。并且出现bug时，两个人一起思考流程，找出错误原因的效率高于一个人。
3.有的时候虽然会出现流程设计上的分歧，但是不同的设计方案，反而拓宽了思路。并且如果之后要重构，也可以快速的采用另一种方案。
4.结对编程有一点不太好的就是，全程不可能由一个人一直写代码，因此会导致代码的风格不一样。比如说一个人在写的时候喜欢用驼峰法定义变量名，而领航员此时并不会太注重他使用的到底是什么方法，只要能见名知意即可。但是当两者换位时，另一个人可能习惯于用下划线来命名变量。这样一来导致整个代码的风格不一致而且两个人未必会发现这个问题。
5.结对编程乐趣大于一个人，成功可以一起分享喜悦。而失败之时，两个人可以一起努力调式改进。
二、对接总结
1.在接口方面一开始完全不懂，就很奇怪为什么不直接给一个头文件，多简单方便。后来老师提到头文件就把源代码也泄露出去了才恍然大悟。
2.通过在VS下建立dll项目，生成.dll .lib文件。再将.dll .lib .h文件提供给调用方。我们自己测试的时候使用的方式就是普通的隐式调用，新建了一个cpp按照网上的方法没有出现什么大问题。
3.与第11组对接时，由于是第一组所以对dll的调用还很陌生，使用了很多方法，出现过无法解析函数、无法连接.lib等问题。最后采用添加.h文件，并include在主函数中，再将.lib和.dll文件放在工程当前目录工作目录下，加入#pragma comment（lib,"x:\xx\xx\Core_x64,lib"）绝对路径的方法成功对接。
4.与第10组对接时，反映说Setting（之前是这么命名的）函数和他们定义的某个类重名了。想了一下Setting的函数名确实过于简单容易重名，所以索性改的长一些Setting_Parameter（），一来不重名、二来更能表达作用。还有一点就是对方反映会输出0‘1\2这样的分数，我们回去查看了一下代码发现在测试与0有关的bug的时候把判断句注释掉了，于是赶紧去掉注释再测试不再出现这样的问题。
5.与第3组对接时，反映说不知道我们对于参数输入错误时的打印在哪里（我们在说明文档中提到参数错误会打印出”error xxx“）。想了一下当时是想做个简单的入口检测避免数组上的越界崩溃，不过想的简单了仅仅用了printf。虽然参数错误Setting_Parameter函数会返回-1不再执行Generate函数，不过简单的printf在运行exe下可并不会出来，算是想简单了白写了printf。好在UI组能力强可以根据我们的说明自己做入口检测。
6.与12组对接时，接口本身没有大问题，不过对方建议到我们的代码变量命名风格有差异，也就是上面提到的第4点。经过对方的提醒我们也才意识到这个问题，之后也会记住，尽力统一可以统一的代码风格。