我爱结对—结对爱我

教学班级	2021春季软件工程（罗杰 任健）
GitLab相关地址	2021_pair_work
两位同学的学号后四位	3480@dxh，4216@js

结对项目实践反思

问题分析

针对前面两个阶段中出现的问题，分析问题的特征、产生的根源和对质量的影响程度

（个人觉得在两个阶段中出现的问题与结对形式的关系似乎比与代码本身的关系更加密切...)

• 第一阶段由于作业暂时比较简单，只要抽象出文件和目录两个大类即可，于是在浏览完指导书后，我和队友都没有迅速投入作业的战斗中（所以有时候两个人摸🐟比一个人摸🐟更可怕）。在作业发布后的第二天晚上，我们终于开始正式结对了。

  一开始为了响应课程的号召，我们决定 一人驾驶一人领航 ，但经过一晚上的实践发现，两人都比较习惯独立工作，特别是两个脑袋凑在一台电脑面前就更加无法工作了，因此我们一晚上收获了几十行 bug 频出的代码。为了尽快完成整体架构，我们先使用各自的电脑独立完成各自的类，然后在某台电脑上完成合并后再一起完成一些综合方法的编写。

  虽然看似也没有太大的问题，但在合并的过程中还是有一些意想不到的情况出现：

  • 命名规范问题。 由于类是我和队友各自写各自的，所以两个人的命名方法风格迥异，可能对代码的正确性不会产生影响，但整体看上去非常奇怪，有时候也会影响到代码的可读性。当然这是由于我个人爱用下划线命名的锅，但是我想如果两人在一起真正结对写码的话，队友肯定在当时就会及时纠正，而不用在事后对整个类大动干戈了。

  • 对整体架构的不熟悉。 在我们 “形式化” 的结对过程中，虽然在我们完成各自类的编写后一起完成了综合方法的编写，但在涉及到对方相关的变量与方法时，相关负责的同学就会承担主力工作而不需要另一方做太多思考。于是，虽然大家的确是结对编程，但思想上可能还是不能形成整体。这也导致后来我们在 为对方模块做测试 时，有些方法无法理解到可能出错的点。即使最后通过交流探讨能够到达和对方一致的熟悉效果，但此时已经浪费了大量的时间，有些得不偿失，最终的测试效率也并不是太高，因而对于代码的质量可以说是有很大影响。

    在之前的阅读作业中我提过关于单元测试是开发人员自己编写还是他人编写的问题，还记得当初我自己是倾向于让其他人员编写的，但是现在我好像有点理解了《构建之法》2.1.2中所说的：

    

    代码的作者是最熟悉代码的人，写单元测试也没有比作者更适合的人了。✔
• 进入第二阶段时，我们吸取了第一阶段的教训，在发布指导书后不久便开始工作了，这次为了让两人对整体都比较熟悉，我们克服种种不适开始一起写码，但是又因为一些原因，我们还是出现了一些意外情况：
  • 两人共同的 “坏” 习惯。我与队友都比较喜欢看完指导书后进行一段时间的整体架构设计，在完成全部设计前我们都很少看ISSUE上面的提问，这也间接导致了在第二阶段的后半段进程时间内我们的程序出现了大量与指导书不符的行为，在 debug 的过程中又造 bug，过程推进得比较艰难，测试也没有很好的完成。问题的根源感觉可能是我们 无法拎清核心需求。尽管本次作业更正了很多内容，但大部分其实与我们最初的想法是一致的，还有比较复杂的也明确标注了不会测试，但是几十个ISSUE一次性看下来还是让我们的思维比较混乱，在一些无关紧要的细节上拿捏不定，浪费了大量时间的同时也对心态造成了一定影响，对于质量的影响程度也是较大的。
  • 关于TODO。 由于本次作业相较于上次作业复杂了很多，对于一些暂时无法确定的问题我会表上 TODO，但是回头看时往往忘记了到底要注意什么细节，这也算是我的编码陋习吧...但在后来还是会详细写上疑问点，对代码质量影响不大。

总结结对项目中的需求分析实践体会，并分析哪些bug是因为需求分析不足而带来的

• 关于需求分析的实践体会主要还是第二阶段的

  ln

  、

  ln -s

  cp

  和

  mv

  ，其中主要的需求分析不足体现在以下三个方面：
  • 很多 不再赘述 的情况在编码的开始没有考虑完全，导致后来在添加一些功能时让整个代码的分支判断过多，结构也比较混乱。例如在

    mkdir

    中的三个异常在下述指令中都不再赘述，如果在阅读到此处时没有将异常标注在下方所有相关指令中就很有可能在写到后面的时候遗漏相关情况。
  • 关于

    cp

    mv

    等指令的 属性修改问题。由于文件或目录有很多例如 创建时间、修改时间、创建者等属性，那么在移动以及覆盖的同时到底以哪个属性为准呢？在后来的解释中我们看到 视作对...修改一次 就取...的创建时间和使用者，关于修改时间都取当前时间即可，其他属性也按照原来文件或目录为准。
  • 关于 是否重定向 的问题。如果需要重定向就直接对所定向的文件进行修改，如果不需要重定向就按照文件一样进行操作即可。
• 以上需求都是属于指导书中讲述较为清楚的地方，但因为分析不足也导致了部分 bug 的出现，所以对于需求还是值得我们花较长的时间好好分析的。如果直接上手写代码，可能会很快，但更有可能之后花很长时间修改与纠错。

总结结对中的架构设计实践体会，描述通过改进设计来提高程序的性能改进的思路和方法，并分析哪些bug是因为架构设计不足（特别的，需求变化）而触发的bug

架构设计：

• 在第一次结对编程时，我们创建了接口，并且使目录类和文件类实现了该接口。在用

  HashMap

  存储的时候无需分开存储，只需要存储接口，并且在许多判断的地方都无需重复判断。在接口声明两个类中相同的方法后，在使用方法时，也无需判断是目录还是文件。利用借口提高了写代码的效率，并且降低了出bug的可能性。

• 在第二次结对编程时，增加了硬链接和软链接，并且使这两个类也实现了接口，在这两个类中增加了方法。这使得在修改第一次作业的函数时，不需要太大的改动，直接判断即可。

  但经过反思后我们认为，如果采用继承会比接口更为合适。因为目录、文件等都是相似的物体，具有类似属性，而并非行为，所以从含义上来看，继承更合适。同时从编码过程来看，四个类都有几乎相同的方法，但一旦有错误，需要同样地修改四遍，而采用继承在修改时会较为方便。

  同时，硬链接和软链接应该先继承链接这个类，链接再与目录、文件继承同个类。否则，会导致目录中有一些不应该有的成员变量和方法。

bug分析：

• 如上述，当类的方法错误时，需要修改四次，这就导致了出现有一个类忘记修改的情况，经过测试后找到了这个bug。
• 同时，由于在第一次结对编程时，将所有目录和文件的绝对路径都在创建时保存，这样虽然在第一次作业时比较方便，但第二次结对编程时，需要移动和复制，会改变所有子目录和子文件的绝对路径，所以将绝对路径的实现方式改为需要时查找，因为需要修改的方法比较多，所以在修改过程中会出现一些bug。

总结结对过程中的进度、质量和沟通管理实践体会，并分析哪些哪些bug是因为两个人的理解不一致而导致

• 两次结对编程都因为文件和目录大小的问题有bug。因为编程的习惯以及写代码的分配，故查询文件大小的时候采用了需要时计算的方式，查询目录大小的时候采用了存储的方式，每次变化时修改目录及所有上层目录的大小。

  故在方法对文件大小进行修改或者需要复制移动文件时，同时需要修改目录及所有上层目录的大小。由于对于正负和参数是目录大小还是变化量这些问题理解上的不一致，导致在改变文件后计算目录大小的过程中出现了一些bug。

• 大多数时候我们两个人理解不一致时，会进行沟通，直到一人将另一人说服，沟通虽然会花费较多时间，但是也使我们对题意的理解更加深刻。

提出建议：根据三个阶段的结对项目的实践经验，对如何更好的实施和管理结对项目提出自己的建议

• 在开始结对编程前应该出一套较为详细且正规的设计文档，包括命名规范、类的各种属性以及方法的运用等，以防在具体实践过程中一边编码一边设计规范，浪费时间的时候对代码质量也产生了一定影响。
• 在时间充足以及两人相互了解程度比较深的前提下尽量考虑使用一台电脑编程，毕竟两个人对代码的审查总归是要比一个人单独写代码要更加严格一些。但有问题的时候要及时提出并及时解决，一定不能拖延，即使有的问题暂时无法下定论，也要在旁边做上详细的标注，方便回头进行查看。
• 对于需求要加深认识。要明确判别核心需求与变动需求，对于变动需求如果不影响大局可以先暂时不管。同时如果对某一核心问题存在严重的分歧一定要及时统一意见，无论听哪一方的都要有理有据，可以讨论，但一定要给出明确的结果。

CI体验感想

通过这次结对编程，你对CI的使用体验如何？你对这一工具有何认识？

总体来说本次 CI 的使用体验还是良好的（除了在第一次使用时花了近一节课的时间才配好配置文件触发测评外）。这一工具可以说让测评更加自动化和直观化，在具体使用过程中便利性主要体现在两个方面：

• 修改完代码并通过 git 上传到代码仓库后可以直接自动触发测评，及时查看反馈信息，不用再做提交等冗余操作，在一定程度上节省了时间，提高了编码效率。
• 可以进行 Junit 单元测试并实时计算覆盖率。关于单元测试也可以查看具体细节，总之让上传-测试-提交的过程进行了一体化。

总之虽然开始上手有一些困难，但是后来测评的便利性说明了之前的摸索还是值得滴...

结对编程感想（对队友/自身的评价、过程中遇到的困难与收获、锻炼了哪些能力

描述你们结对的方法、结对过程中遇到的困难与收获，结合自己的结对经历，说明结对编程的优点和缺点，分享可以推广的结对妙招

• 在此次结对过程中，个人觉得还是遇到了不少的困难。首当其冲的就是第二次作业的任务量猛然加大以及混乱的多次 commit ，让我个人一度熬夜到怀疑人生... 其次就是时间安排有一点紧张，虽然现在看来真正的结对编程只有两周时间，但是就本组来说基本上除了上课和必要的休息时间外，其余时间都花在了结对编程中。最后是关于集成测试方法，感觉到最后可能也就是仅仅使用了该方法，也感受到了便利，但并没有对其真正理解。（还有在代码都已经无暇顾及的同时还要写博客作业，个人觉得博客很多时候抒发的是大家自己的想法，甚至有点周记的感觉，其实可以更加精简一些... ）
• 关于结对编程的收获我可能真的需要仔细说说：
  • 就我们个人来说，我们一开始配合得并没有很默契，对一些问题的解决方式都不敢下太果断的定义，但后来在 敏捷开发要求以及多变需求 的推动下，我们对于一些问题的决策明显果断了许多，两人之间的交流也更加高效了。总的来说，对我们的合作能力都有一定的提升。
  • 关于对需求的分析能力也有一定的提升。第二阶段的作业分支情况较多，有很多细节需要考虑，这对我们的需求分析能力有很高的要求。
  • 最后是与他人合作的能力。这可能是我第一次与他人一对一进行合作的经历，肯定会有缺陷和遗憾之处，但是也带给了我很多的思考和感悟。以后的学习生活中我也已经会再次经历这样的过程，本次结对编程也算是对我的一次提前演练吧...

• 结对编程的优缺点及“妙招”

  优点：见以上结对编程的收获

  缺点：见以上结对编程遇到的困难

  妙招：如果要谈“妙”招，我个人觉得可能得与他人的方法有一定的区分度，并且有一定的技巧性。所以就此看来，我们并没有任何妙招。虽然测试的时候出了一些 bug ，但是我们也的确尽可能地考虑到所有的情况（由于结对的两人选课的重复度较高，甚至感觉一周都整天混在一起结对编程），总而言之还是比较踏实地完成了两次作业。以及无论是合作的默契度还是作业完成的顺利程度，个人感觉一是与能力有关，二就应该与时间相关了，如果真的想让大家深入体验就应该投入更长的时间循序渐进，而不是浅尝辄止，想一口吃个胖子反而消化不良，后来两个人由于都休息不足导致精力可能不太集中，还是希望下一届结对编程的体验更加友好吧~

评价你的队友，使用汉堡点评法评价你的结对伙伴，务必给TA 提改进意见。

• from 3480 to 4216

  首先感觉俺的队友还是很靠谱的，在各种比赛的压力之下还是腾出了很多时间与我进行结对。由于我个人在分支比较多的时候容易思路混乱，会写出一些比较奇怪的bug，队友也比较善于发现代码中的问题。meat 可能就是在最后的时候我和队友的心态由于ISSUE过多都可能有点小崩，所以如果以后有机会合作的话还是要多锻炼自己的心态🙈

  最后能和 JS 在一起合作还是很开心的，为我们的革命友情干杯🍻

• from 4216 to 3480

  干杯干杯🍻

  同样觉得我的队友非常靠谱认真，我们遇到问题都会一起讨论，遇到分歧之后会仔细解释自己的想法，直到两个人都对此表示认同，在沟通上一直是非常完美的规范阶段和创造阶段（见《构建之法》4.6），这就让我们一直专心于代码的实现。虽然在后期因为ISSUS很多，需要修改的地方很多，花在沟通解释上的时间较长，但这也让我们对题目的理解更加细致。

  最后感谢DXH同学pick me，友谊万岁！🍻

描述在本次结对编程的过程中，你们使用了哪些软件工具，是如何应用于实践的。

• 代码：IDEA （老朋友），MAVEN（项目管理以及导出覆盖率信息）
• 测试：JUNIT实现单元测试（对于找BUG可能有点困难，但是对于极端情况的测试还是很有效的）
• 博客：TYPORA （简单又好用，写文档首选，YYDS）

描述通过本次结对编程的感悟和体会，对本次作业的有哪些想吐槽的，觉得本次结对作业内容可以在哪些方面做出改进？

• 个人感觉首先如果有了指导书的话应该严格按照指导书进行，而不是一会指导书一会LNIUX，用户需求的确是变化的，但用户应该不太会变并且需求的变化也是可见的。其次是过于咬文嚼字，特别是视作对XXX的修改一句话颇有深意，让语文水平逐年下降的我感到摸不着头脑，指导书不应该让大家更快更方便地理解需求吗？用户需求变可以理解，变得快也可以理解，但变得让人故意掉进坑里就有点奇怪了... 最后如果真的想培养大家的 协作能力 而不是代码能力，借用群里的一句话：“侧重“结对”、“协作”、“工程”等方面而不是代码本身”。
• 个人感觉整个编码过程中，花费时间最长的就是对指导书的理解问题，首先不再赘述、视作修改一次、按出现位置靠前等描述，我们需要花费大量时间补充罗列这些情况，在期间有许多不理解、许多分歧，中华文化博大精深，我认为语言的表达，有时并不只有一种意思，每个人的理解都各不相同。部分情况按照指导书、部分情况按照实际系统，那是否只有把所有情况列举出来归类才能保证绝对的正确？这也就导致ISSUS中出现许多细节情况的询问，我们在写完代码之后，需要把所有的ISSUS阅读一遍，理解提问者的意思，助教的意思，然后再想自己的代码该如何修改才能判断这种情况。特判？那别的细节呢？修改架构？那别的细节呢？我从不认为一个工程需要关注的不是整体功能，而是抠细节情况。除此之外，我不认为我们的语文水平有问题。当然，我说的很有可能是错的，毕竟........。