有了第一次的基础，第二次的大作业相比之下要简单不少。
由于这一次是两人结对编程，所以选择一个合适的同伴至关重要。我的同伴虽然不是同一个宿舍的舍友，但是相互之间也非常熟悉，所以不会有沟通上的问题。
找到了同伴才仅仅是一个开始，由于这次的作业是在第一次作业的基础上进行改进，而考虑到第一次作业是一项个人作业，所以这次结对项目以谁的程序为蓝本做改进也是需要解决的问题之一。由于我对自己的程序过于自信，所以毛遂自荐用自己的程序来进行改进。而看到我这么自信，同伴也没有反对。可是，就是这样不严谨的准备过程使我们在后来遇到了一个不小的挑战。
在第一次的项目中，我已经将自己的程序进行了封装，所以无需做过多的改变的就能直接应用。但是由于这次的项目要有用户界面，所以整个流程的控制就不能继续在代码中用命令行进行了。我们选择的是Qt这个软件，主要的原因就是因为它比MFC更简单快捷小巧，而且可以直接应用第一次项目的c++代码。我的任务就是清理好第一次项目的代码，并明确留出接口以及相应备注。
完成了我的任务，剩下的就是将同伴设计的UI整合到一起了。我们组没有选择类似计算器的界面布局，主要原因就是我们做的是一个四则运算生成软件，而不是单纯的计算器。所以，我们所有的数字与符号输入都是通过文本框进行的，而不是按钮。这样做不但能提高用户输入的速度，而且还减少了界面当中按钮的数量，使界面更加简洁。
在设计界面的过程中，针对一个问题我们产生了不统一的意见。问题很简单，就是作完一道题目是否自动转到下一道题目。我的观点是无论做对做错都不自动转到下一题，因为该软件的目的是联系，所以无论做错还是做对，用户都有是否重复练习一道题的选择权。而我的同伴认为，该软件的目的是统计做题效率，每次按一个按钮显然浪费时间，而且如果能够重复做一道题，统计做对了多少道题就变得相对比较困难了。考虑到一开始的用户需求明确规定了要能够显示做对的题目数量，最后我们还是按照他的想法，更改了程序的逻辑。
完成了程序与界面的整合之后，我的同伴负责进行了测试。然而一个意想不到的问题出现了，在程序正常运行时，如果连续点击生成题目文件的按钮，程序会有一定几率崩溃。毫无疑问，这个问题在我的源程序中就已经存在，因为我基本没有更改任何代码的逻辑，只是进行了整理。可是，在检查第一次大作业的时候什么意外却都没有发生。经过1天的苦思冥想，各种debug，各种printf，我终于找到了问题的关键。其实，问题很简单，在第一次大作业时，为了能够让程序自动生成合法的题目，程序需要能够自己检查随机生成的题目是否由除零现象，而在检查到除零现象时，我的做法是把除零当做乘零来计算并返回无效标志，这样就可以抛弃这道题而重新生成一道题。
而在返回无效标识的时候，尽管我意识到了立即返回可能会造成意想不到的错误而选择了继续当做乘零计算，但是并非所有函数都把除零当做正常运算来做的。在一个高层函数中，当它发现底层函数返回的标志是无效时，他也直接返回了无效，而没有将栈内的除号弹出，从而造成了符号与数字的个数不对应，当程序继续正常运算这个表达式时，就出现了数字栈为空，符号栈却非空的现象。由于这种情况只发生在除号已在栈内并且之后的符号计算结果为0的情况下，所以并不是很容易出现。而且，由于第一次大作业是命令行窗口，而且没有设计可以重复生成题目的功能，所以遇到这个bug的几率进一步下降了。
尽管这个问题并不难解决，但是它所揭示的问题却足够引起我们的重视。在一个项目之初，确定蓝本的时候一定要进行充足的测试。两人合作时，哪怕你的同伴是你最相信的人，也不要完全放心的把一切交给他，必要的检查既是自己应尽的义务，也是对同伴负责的体现。