软件工程 张雯雯 223201062202
2.1实验过程
2.1.1实验代码
给出博客园截图和网址，并附上github的代码地址。
GitHub代码地址：
创建四则运算 ·张文文02/-@d300769 (github.com)
博客园网址：
软件工程 张雯雯 223201062202 - 雯雯Y - 博客园 (cnblogs.com)
2.1.2实验过程
(1) 本人角色
自己在本次结对项目中所担任角色，以及结对伙伴姓名学号。
本人角色： 领航员 张雯雯 223201062202
结对伙伴姓名： 驾驶员 刘丽媛 223201062216
(2)
根据驾驶员和领航员的工作分工，分别撰写。
驾驶员：系统的实现过程、算法设计、结对工作照片等
领航员：代码测试覆盖标准、测试用例、代码检查表、工作记录表等。（本部分具体可以参照实验一的撰写方法）
本人角色为领航员，实验过程如下：
代码测试标准为语句覆盖；
测试用例：
（1）3，20，1，0，1
（2）2，50，2，1，1
（3）1，60，3，0，1
流程图如下：
测试过程：
语句覆盖测试：即每一条语句都执行一遍
测试数据（1）3，20，1，0，1
测试结果如图1所示
图1
测试数据（2）2，50，2，1，1
测试结果如图2所示：
图2
测试数据（3）1，60，3，0，1
测试结果如图3所示：
图3
测试截图如图4，5，6所示：
图4
图5
图6
代码审查表如下：
|
功能模块名称 |
四则运算式生成模块 |
||
|
审查人
|
张雯雯 |
审查日期 |
2022.11.07 |
|
代码名称 |
Shuchu |
代码作者 |
刘丽媛 |
|
重要性 |
审查项 |
|
|
|
重要 |
头文件和定义文件的名称是否合理？ |
|
|
|
重要 |
头文件中是否只存放“声明”而不存放“定义 |
|
|
|
程序的板式 |
|||
|
重要性 |
审查性 |
结论 |
|
|
|
空行是否得体？ |
是 |
|
|
|
代码行内的空格是否得体？ |
是 |
|
|
|
“{” 和 “}” 是否各占一行并且对齐于同一列？ |
是 |
|
|
重要 |
一行代码是否只做一件事？如只定义一个变量，只写一条语句。 |
否 |
|
|
重要 |
If、for、while、do等语句自占一行，不论执行语句多少都要加 “{}”。 |
是 |
|
|
重要 |
注释是否有错误或者可能导致误解？ |
否 |
|
|
命名规则 |
|||
|
重要性 |
审查项 |
结论 |
|
|
重要 |
命名规则是否与所采用的操作系统或开发工具的风格保持一致？ |
是 |
|
|
|
标识符是否直观且可以拼读？ |
是 |
|
|
重要 |
程序中是否出现相同的局部变量和全部变量？ |
否 |
|
|
|
类名、函数名、变量和参数、常量的书写格式是否遵循一定的规则？ |
是 |
|
|
表达式与基本语句 |
|||
|
重要性 |
审查项 |
结论 |
|
|
|
是否编写太复杂或者多用途的复合表达式？ |
否 |
|
|
重要 |
是否将复合表达式与“真正的数学表达式”混淆？ |
否 |
|
|
函数设计 |
|||
|
重要性 |
审查项 |
结论 |
|
|
|
参数的书写是否完整？不要贪图省事只写参数的类型而省略参数名字。 |
是 |
|
|
|
参数命名、顺序是否合理？ |
是 |
|
|
|
参数的个数是否太多？ |
否 |
|
|
|
是否使用类型和数目不确定的参数 |
否 |
|
|
|
是否省略了函数返回值的类型？ |
是 |
|
|
|
函数名字与返回值类型在语义上是否冲突？ |
否 |
|
|
重要 |
是否将正常值和错误标志混在一起返回？正常值应当用输出参数获得，而错误标志用return语句返回。 |
否 |
|
工作记录表
|
项目 |
预计 |
实际 |
|
设计时间 |
9：30 |
9：30 |
|
编码时间 |
10：20 |
10：20 |
|
测试时间 |
13：00 |
13：15 |
|
代码行数 |
192 |
192 |
|
测试代码行数 |
21 |
21 |
|
错误数量 |
0 |
0 |
|
错误修复时间 |
无 |
无 |
|
开发总时间 |
四小时 |
四个半小时 |
3 总结与体会
对队友的评价：
第一次一起合作，过程很愉快，合作的也是相当默契了，我们分工明确，她作为导航员用很短的时间就编写好了程序，并且没什么错误，是位很厉害的同学了，代码的缩进、排列整洁美观，大致思路清晰，主函数方面关键转折点的注释也恰到好处，整个主函数的可读性非常强。代码有着简洁的优点，比如代码中的判断语句就是从主函数中独立了出来，在外部成立了一个函数，这样子每次进行判断就只需要调用判断语句，而不需要每次都写一次判断语句，这样既降低了程序员工作时的工作量，也降低了同组成员看代码的难度。
在我做测试时她也耐心帮助我完成测试，一开始我对测试并不怎么熟悉，一步一步的很慢，后来她细心教我，使我很快完事了测试部分，我觉得这应该就是结对编程的目的了吧，互帮互助，长短互补吸收对方优点加快工作的效率，效果更为显著，培养同学之间的交流沟通。总而言之，此次结对编程我们两个人完成的很顺利。
总结：
通过本次结对编程实验，我发现结对编程确实是一种提高编程效率的方式，在旁面对驾驶员所操作的每个步骤，每个过程，都看在眼里，同时可以给出恰当的建议，在代码规范上，首先变量要明确，命名要规范，括号要有层次感，虽然有时驾驶员擦觉不到，但是领航员在旁边观察的非常清楚，所谓当局者迷，旁观者清，也一定程度上验证了这个道理，这样通过交流，沟通，小层面上讲是技术上方法上的提高与创新，提高了代码的质量与工作效率，从大的层面上讲也是一种思维的碰撞与跨越。
但是也发现结对编程一些缺点：1.如果两个人水平参差不齐，很容易出现抱大腿现象。2.在一些不必要的细节上发生争执，影响效率3.领航员素质不好会影响驾驶员的编码进程4.沟通能力不强会影响效率。不过我和我的小伙伴就没有存在这些问题，从设计到编码再到测试一切都比较顺利，也会遇到一些各种各样的问题使我们止步不前，但通过搜集材料，向同学求教，问题最终得以解决，本次实验学到了好多东西，也很开心和小伙伴的这次合作！
