结对编程心得---------优秀的队友是成功的一半

Posted 2020-10-31 USTCPaladin

一，结对编程的收获

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组所考虑的内容。