一，结对编程的收获
1.团队分工
结对编程作业大部分的时间都是采取共同编写代码，即“一个做驾驶员，一个做领航员”，驾驶员负责敲键盘，领航员在一侧提供建议、检查错误或帮忙搜索相关的资料。
就这次团队项目而言，我们合作还是很愉快的。清明节的后两天我和朱池苇同学一起学习了Qt。由于朱池苇同学的工程能力比较强，所以大部分程序都是朱池苇同学作为驾驶员，而我（刘鼎乾）则作为领航员，与朱池苇同学对问题进行讨论，查找资料，检查错误等。
2.结对编程的意义
我觉得结对编程确实具有非常重要的意义：
- 一个人编写代码，总是有种灯下黑的现象。可能你自己犯的很微小的错误，你花了大把大把的时间，还是搞不出来。而另一个人只需要看一下就能指出，这提高了复审效率。
- 可以不断从别人那里学习，提高自己的水平。这次结对编程，我从朱池苇大佬那里学到了很多，比如良好的代码风格，清晰的编码思路，以及熟练的调试技巧等
- 通过两个人的讨论，更好的解决问题等。
3.代码的可读性
以前数据结构的助教说我的代码可读性差，这是为什么呢，这里附一段我以前写过的代码：
1 unsigned long long a;
2 int b;
3 for(int i=0;i<10000;i++)
4 {
5 cin >> a >> b;
6 switch (b)
7 {
8 case 1:
9 charu(a);
10 break;
11 case 0:
12 chaxun(a);
13 break;
14 default:
15 break;
16 }
17
18 }
19
20 cout << n2 << "/" << n1 << endl;
21 cout << m2 << "/" << m1 << endl;
22 return 0;
a是什么，b是什么，n1 n2又是干什么的呢？不仅没有注释，而且用的变量名也非常不好。
而这本书给了很多提高代码规范的建议，比如：
- 缩进，一般以4个空格
- 行宽，不多于100个字符
- 用括号清楚地表达优先级
- 断行与空白的{}行
if (condition1)
{
Do something;
}
else
{
Do something else;
}
一般用这种方式会让人觉得层次清晰，逻辑分明
- 命名！想我之前写的那段程序，最主要的问题之一就在于没有命名。我以前觉得命名无所谓，但现在觉得，好的命名要让人能够见名知意，这对提高代码可读性是重要的，很多程序员为了一个好的名字还想半天。一般可用下划线来构造很好地命名。
注释，没有注释的代码让人读起来很痛苦，而好的注释主要是告诉别人这个程序在做什么，为什么这么做，以及需要注意的东西。这样别人读起你的代码才不会很痛苦。
于是乎我们就要问，为什么我们需要好的代码规范？为什么我们需要别人看懂我们的代码？
这在结对编程中，尤其重要。假如说没有人看得懂你的代码，结对编程也就只是纸上谈兵了。
4.好队友的重要性
这次结对编程，我从我的队友朱池苇同学身上学到了很多。他的工程能力很强，代码可读性也很好，而且思路也很清晰。能经常和这样的队友结对编程，我突然对能否最终调试成功充满了信心。这说明了，结对编程的队友有多重要。
二、对接的收获
UI主要工作量集中在设计界面，代码量并不大，大概在300行左右（除开Qt Creator生成的代码，自动生成的代码在1500行左右）。但是对接的时候，各组Core的API甚至逻辑功能的差别，给我们带来了巨大的麻烦。
首先是逻辑层面，有的组要求加减、乘除分别绑定，而有的组要求可以单独支持任一种运算；有的组要求小数和分数不能同时存在，而有的组要求一个式子里既有小数又有分数，这样的情况下，同样的UI界面不可能满足所有Core的要求（比如QRadioButton选项互斥，而QCheckBox可以复选，不支持复选的 core用了QCheckBox，就会造成非法输入），也许需要根据不同的core发布不同版本的UI。但这个工作量显然太大了。
另外则是每个组的接口参数不同，需要编写不同的接口转换代码，而且代码量的高低，很大取决于API的好坏。本次所有Core中的API主要分为三个档次：
第一档：接口函数少，传参合理，可以直接把UI获取的用户作为函数参数。这样的接口，对接代码量是最小的。
这是第一档的接口代码：
//setting
set_setting(oNum-1,ui->oUppRange->value(),ui->precisionSpin->value(),ui->fraction->isChecked(),ui->real->isChecked(),ui->mulDiv->isChecked(),ui->power->isChecked());
// generate one question and one answer (loop this)
std::string *question = new std::string();
std::string *answer = new std::string();
generate(&question,&answer);
ui->questionBrowser->setText(QString::fromStdString(*question));
ui->answer->setText(QString::fromStdString(*answer));
第二档：接口函数多，传参合理。这是本次大部分组core的API所处在的档次，这种API把setting的每一个参数分别设置为一个函数，需要单独传输，但是参数设计合理，可以直接将用户输入作为函数参数。这样的接口，setting的代码量较大，有时需要做用户输入到core接口的转换（例如“是否支持小数/分数”的参数是0,1,2，但UI得到的数据是选择框是否被选中的布尔型，因此要先做逻辑判断，再进行转换）。
这是第二档所需要的接口转换代码（为了避免可以看出是哪一组，我对函数名作了修改）：
//setting
core.setQueNum(ui->qNum->value()); core.setDataNum(ui->oNum->value()); core.setRange(ui->oUppRange->value());
core.setAccuracy(ui->precisionSpin->value());
//set operator type if(((ui->mulDiv->isChecked())&&(ui->power->isChecked()))==true) core.setOprType(3); else if(ui->mulDiv->isChecked()==true) core.setOprType(2); else core.setOprType(0);
//set operand type if(ui->fraction->isChecked()&&(!ui->real->isChecked())) core.setDataType(2); else if(ui->real->isChecked()&&(!ui->fraction->isChecked())) core.setDataType(1); else if((!ui->real->isChecked())&&(!ui->fraction->isChecked())) core.setDataType(0);
//generate all questions
question=core.getQue();
answer=core.getAns();
ui->questionBrowser->setText(QString::fromStdString(question[0]));
ui->answer->setText(QString::fromStdString(answer[0]));
//loop this (i is defined in the header file)
if(i<totalQNum)
{
ui->questionBrowser->setText(QString::fromStdString(question[i]));
ui->answer->setText(QString::fromStdString(answer[i]));
i++;
}
第三档：最差的一档，函数多，而且参数设置不合理。
某一组，曾经将所有的函数的传入参数全部设置为了字符串！！！这意味着什么？意味着UI组要将所有得到的整形、布尔型先进行逻辑判断，再转化成对应的字符串，最后再调用接口函数。而当我们为这个组的接口编写了复杂的转换代码并实现了之后，这个组将API改回了直接传参的模式。（就不贴代码了）。
（这里对号入座太简单，在这里对那一组说声抱歉，但是我实在很想吐槽这一点）
不难想到，实际上这种输入为字符串的方式一定也给core组增加了工作量，那么他们为什么会这样做？
我可以理解这个core组的想法，可以说出发点是非常好的，他们希望自己的接口更加“易懂”，对于最终用户，什么东西最好懂？当然是自然语言！比如，字符串“precision”代表了“精度”，“+-*/”代表“加减乘除”，函数的功能是简单易懂的。但是他们忽略了一点，这种考虑应当是相对于最终用户，也就是使用这个软件的人而言的，而不是相对UI编写者而言的。对于UI编写者，只需要定义清晰易懂的变量名、提供能够理解的API文档，就足够了。而如何用自然语言去通俗易懂地表述输入要求，应当是我们UI组所考虑的内容。