一,结对编程的收获
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组所考虑的内容。
原文地址:https://www.cnblogs.com/ustcldq/p/8892420.html