结对项目内容：http://www.cnblogs.com/jiel/p/4830912.html
结对成员：康家华，马腾跃（http://www.cnblogs.com/summerMTY）
[附加题]第四阶段目标 - 界面模块，测试模块和核心模块的松耦合。
对于这个附加题，我们小队（A）决定和刘乾小队（B）的模块进行交换，于是在拿到对方的代码时，我们立刻就傻眼了。
不是说对方写的很差，相反，B小队的代码有刘乾的保证，质量很高。让我们傻眼的是因为我们的想法不是完全相同的，而我们设计的接口的要求和他们设计的接口的要求不同，导致界面模块、测试模块不能和他们封装好的Core进行衔接。
所以现在怎么办？可以说，我们设计的这三个模块——核心模块、用户界面模块和测试模块——在开始时就是衔接好的。测试模块就不用说了，根据接口和各种分支设计出来的能够99%+覆盖核心代码的测试用例；用户界面模块也是一样，或者说核心模块在一定程度上是为了用户界面模块进行了一些修改。于是，现在就处于一种“牵一发而动全身”的状态，到底要不要为了契合B小队的代码而进行修改呢？
为什么会出现如今这种情况？我是这样理解的：首先，主观能动性决定了我们必定有着不一样的想法，我们在对需求分析的时候不能做到百分之百地一致；其次，多样的编码方式和设计方式也决定了我们很有可能产生差别，比如我使用了另一个函数来进行参数的设定，而你通过传参的方式设定了参数；最后，我们两个小队分开作业，两者之间也没有交流过，可能产生“蝴蝶效应”，从一开始很细小的偏差（如一个函数的返回类型）到最后形成很大的区别（如一个类的功能）。
思前想后，用一种最中立，最优化的方法来进行修改——取长补短。取精华去糟粕，用对方更好的想法来填自己的空缺，我们觉得有特色的保留下来，他们做的比我们好的部分我们借鉴。就比如说我们在看了B小队的界面后，参考着他们的界面也做出了计算器的按钮界面来。
[附加题]第五阶段目标 - 通过增量修改的方式，改进程序，完成对各种错误情况的处理。
“改进程序”这个过程其实我们一直都在进行，从一开始的编程起，我们就在边写边改。
同样的，我们在错误处理上也是边写边想，我们在核心代码中进行了许多错误情况的处理——异常抛出。比如说：
Calculate中抛出了这些异常：
- WrongFormatException // 表达式格式错误
- CalculationException // 运算错误，包括除零等等
- OverflowException // 数字溢出异常
Produce中抛出了这些异常：
- ValueRangeTooSmall // 数值范围太小，生成题目数量太大
Judge中抛出了这些异常：
- JudgeFileOpenFailedException // 文件打开失败
- JudgeFilesNotMatch // 文件不匹配
Setting中抛出了这些异常：
- WrongParameterException // 参数设置错误
- ProducePathNotExistException // 生成路径不存在
总的来说，我们考虑了很多，这也是上学期面向对象课程留下来的习惯（病根），也就是因为这个习惯（病根），我们在写程序的时候总是考虑很多（没有用的东西）。