一，结对编程的收获

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 typeif(((ui->mulDiv->isChecked())&&(ui->power->isChecked()))==true)core.setOprType(3);else if(ui->mulDiv->isChecked()==true)core.setOprType(2);elsecore.setOprType(0);
    //set operand typeif(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组所考虑的内容。