结对过程概述
这次作业是我们第一次采取两人组队的模式，我们在清明节前一晚进行了讨论后，第二天就开始了编程，到今天应该算是有整整两周了。我们大部分的时间都是采取共同编写代码的方式，即一个做“驾驶员”，一个做“领航员”，驾驶员负责敲键盘，领航员在一侧提供建议、检查错误或帮忙搜索相关的资料。
前期主要是对主要的功能进行编写，完成大概架构及基本测试后，后面就主要就是针对一些小问题及一些新出现的要求进行编写，如更改生成随机分数的方式、增加生成整除表达式的功能等等。最后就是通过UI使用后的反馈再进行集中调整。
通过这次作业，我们也体会到了结对编程的优越性。第一天晚上讨论时，我们两个人的二脸懵逼，根本不知从何下手，但第二天开始编写代码后，一点点地深入讨论下去，整个方案也就渐渐明晰了。如果是我一个人面对这样一个项目，难度可想而知。
结对编程的感受与收获
我觉得结对编程的好处在解决问题时体现的最充分。
结对编程时，出现一个问题时，两个人一起讨论总是能比一个人死磕能更快得出结果。个人编程时，难免会遇上一些“坎”而被绊住，这个“坎”或者是遇到问题时想不出一个合适的代码架构或是代码实现方法，又或者是出现了玄学的bug怎么也不知道为什么错了，而两个人一起编程时，每个人的“坎”可能不一样，这样一来，两人互补，“坎”出现的几率也就大大降低了。
当然难免也会遇上一些把两个人都难住的情况，比如我们在思考如何更合适的生成表达式时，就有一段时间没有达成一个很好的共识。由于要求不能出现多于的括号以及不能中间结果出现负数，网上很多找的例子都不能直接拿来用。但两个人讨论时总能碰撞出新的思维火花，我们最后就选择了我们认为最合适的方式，即通过循环，按照运算的顺序逐步生成完整的表达式，在生成的过程中通过比较运算符的优先级以及逐步计算中间结果的方式，来保证不出现不必要的括号以及中间结果不出现负数。
其次结对编程还有一些其他的好处，比如“领航员”可以即时的指出“驾驶员”的一些小错误。而且，结对编程时不是一个人整天坐在电脑前敲键盘，时不时更换驾驶员和领航员的身份，大脑没那么容易死机，这也算是一个好处吧。还有就是出现很绝望的情况时，有一个人一起分担也不会感到那么难受。
接口设计与对接
至于对接上的问题，由于我们抽到的是core组，没有UI那么麻烦。如果当初规定好了接口，所有的UI和core组都遵守的话，自然是好。但在没有规定死接口的情况下，我个人认为，一个好的core组的接口，不一定是拿来就能用，但一定是要是通用的。于是我们设计的是整体是一个类，调用其中的成员函数可以进行设置和生成等操作。考虑到每个设置可能在不同的地方使用，同时为了使设置更自由（或者说使代码更加通用），我们的设置函数都是分开的（如下图），不过也有的UI组表示函数少一些更方便。
图1 set系列函数
运算符这个我们之前是只有三种模式，“+-”、“+-*/”、“+-*/^”，这也是考虑到实际的使用情况。不过后来为了更通用，改成了每一种都可单独设置。其中设置运算符的函数设计了三种，也是考虑到不同UI的需求不一样。我现在觉得其实我可以再提供一个总的函数（很多个参数），这样UI调用这一个函数就能完成所有设置，但是这些分开的设置还是保留。此外，在部分core组的要求下，我们除了提供返回字符串数组，也提供了写入文件的操作。
另外我们遇到的一个大问题就是在DLL封装上，开始照着各种教程一整个下午都没弄好。要么是无法重新生成解决方案（报很多错），要么就是生成了.dll、.lib文件后，在新的项目里无法调用。最初还怀疑是不是由于使用了c++的stl，或者有多个类，类里又有友元函数等比较复杂的东西（因为教程里的通常都很简单），综合很多个教程后，才发现还是问题出现在一些小问题上（不过不得不说有些教程确实不负责任...）。
用visual studio来进行dll封装还是很方便的，可以新建一个dll项目，添加.cpp、.h文件，将代码复制进去，然后关键就是要在.h文件中在那些需要导出的的类或者函数前加上“__declspec(dllexport)”，这一点很多教程都说到了，但很多却没说生成新的解决方案后，使用.h文件时要把里面的这一句改为“__declspec(dllimport)”，导致调用时显示“无法解析的外部函数”。
为了避免修改的麻烦，也可以用条件编译来实现，在 .h文件中加入以下代码：
#ifndef ArithmeticDLL
#define ArithmeticAPI __declspec(dllexport)
#else
#define ArithmeticAPI __declspec(dllimport)
#endif
然后在.cpp文件中加入“#define ArithmeticDLL”这一句，这样在你的项目中就是“__declspec(dllexport)”，在别的使用dll的项目中就是“__declspec(dllimport)”。
还有一个问题就是最好所有的函数、类前面都要加这一句，包括你要开放给外部调用的和你的代码内部调用的，不然会报错。另外，类加了这一句后内部的成员函数就不用加了，但它的友元函数仍然要加。
重新生成解决方案后就会生成.dll、.lib文件了。
作为core组，在对接上真的没有什么发言权，更多的时候只是UI那边对接出现问题时，我们解释一下我们的函数，并且通过UI的反馈，去进一步的优化代码，比如前面提到的运算符设置方式，还有就是小数模式时表达式中操作数的形式问题。这里还是实名心疼一下UI的同学，UI跟core组对接的工作量真的很大，若是最后打分排名的话，也是UI的用户体验上会有一些差别，而core组从实现的结果来看真的差别不大，最多也就差在接口的不同，但是接口你又怎么去评判哪个好哪个不好？我觉得接口只有适合或者不适合，除非是core组把所有能用到的接口的方式都提供了。
不过经过这次作业，怎么说以后在各种方面多少也有点经验了。但我仍然觉得收获和我所花费的时间不成正比，如果以时间为横坐标、收获为纵坐标作图的话，可能只是类似于对数曲线。因为在一些不重要的问题上过多的纠缠，真的其实对能力的提升帮助不大。