结对编程终章 - 结束也是新的开始
| 项目 | 内容 |
|---|---|
| 作业所属课程 | 2021春季计算机学院软件工程(罗杰 任健) |
| 教学班级 | 周五上午 |
| 项目地址 | Gitlab地址 |
| 学号后四位 | 张书恺：3146 李巳辰：3464 |
结对项目实践反思
问题分析-L同学
结对编程时出现的问题主要集中在第二阶段，其主要特征为两人的交流不够深入。由于第二阶段的任务量较大，会涉及到许多细节，时常出现两人对需求的理解不同的情况。然而平时能够抽出共同的空闲时间结对编程的时间又不多，当一个人的实现思路出现问题时另一个人也不能及时指出，这直接导致最终程序质量不高。这样以来结对编程的优势被弱化，因为两个人相互交流而碰撞出的思路必然比一人独自思考更全面。
需求分析实践体会-L同学
需求分析是结对作业最重要的一环，因为其直接决定程序的架构设计。结对作业的需求主要来源于指导书和Issue。最开始应当通读指导书，不能放过每一个细节，对容易忽略的或发生改变的需求最好另行记录。同时这部分分析以两人面对面进行最佳，因为这时的交流是最高效的。不过这往往无法完全解决需求分析的问题，在此之后每当遇到对需求的理解不清晰的情况时应当再细读指导书或Issue、与伙伴交流等。
在第二阶段的结对作业中，cp指令中需要覆盖文件时，覆盖后最终应当以dstName保存，而我们却以srcName保存，还是因为在需求分析时没有仔细考虑导致出现bug。
架构设计实践体会-L同学
需求分析之后就要进行架构设计。架构设计时两人的交流要最好有实质性的记录，比如生成设计文档或直接在代码里设计接口和注释，然后两个人共同对架构设计进行审核。审核越谨慎，编程实现时走的弯路越少。此外，为了方便两人对代码的理解，代码编写前应当制定合适的代码规范，比如分支对应的注释、属性要设置为private等。
第二阶段要在第一阶段的基础上进行迭代，在修改架构时遇到两个主要问题：文件系统和用户系统之间的交互；软硬链接带来的路径寻址问题。前者我们新建一个交互类并采用单例模式用于两个系统之间的信息交换；后者我们利用递归对路径进行解析并返回对应文件或目录类的引用。不过由于各个指令的要求不同，比如有的要求路径末尾是文件，不能有/，而有的既可以是文件也可以是目录，我们在递归时没有充分考虑不同指令的需求，导致程序没有正确抛出异常。现在想来，我们在架构设计时过于仓促，对实体的抽象程度还不够，也没有充分利用多态等面向对象的特性，使得最终的架构不够清晰，还有待改进。
结对过程实践体会-L同学
结对过程中的交流与工作的进度与质量直接挂钩，第二阶段工作的复杂性让我们充分意识到这一点。我们由于中途沟通的失误，工作的进度较慢，最终也是压线提交，同时质量也存在问题。当压力巨大时，任何一方都不能失去耐心，要保证平稳的心态，冷静分析当前的问题。第二阶段的代码编写过程中我们有一次由于沟通不到位，在一个晚上的结对后没有什么实质性的成果，同时又因为临近DDL，双方搞得都不愉快。不过在回到寝室后我们各自都认真了反思，在简短的沟通后各自集中寻找问题解决，最终加班加点完成了任务。
此外在具体编码之后，代码的复审和测试也是一项必不可少的工作。复审可以检查代码规范、清除无用代码；做好测试不仅有利于对各种分支进行覆盖，还有利于进行回归测试，良好的测试能初步保证代码的质量。不过这也是一项繁重的工作，需要两个人配合着进行。
结对项目建议-L同学
-
版本管理：版本管理自然使用Git，不过建议两人同时对代码进行编辑时，编辑部分不要相交，这样在提交时更省事。
-
项目实施：项目实施应当做好时间规划，何时做需求分析，何时做架构设计等（可参考下方表格）。有了明确的时间规划，在结对时就有更清晰的目标，对项目进度也有促进作用。
阶段 开始时间 结束时间 需求分析 架构设计 具体编码 代码复审 代码测试
CI体验感想-Z同学
如上图，我们的结对项目一共进行了92次commit，很难想象倘若缺少CI这样一个自动化持续集成工具，该如何进行频繁的迭代式开发测试。
唯一想吐槽Gitlab-CI的是，既然有完善的Terminal界面，如果能开放输入接口让用户能直接在终端进行部分操作，能简化很多工作。每次修改完脚本后都需要重新提交+漫长的等待时间 属实有点难熬。
结对编程感想
1 结对的总体感受-Z同学
由于我们二人的选修课时段恰好互补，作息时间也很不吻合(究极夜猫子的我背大锅)，所以很难做到像书上那样全过程线下面对面双人结对编程，因此我们采取的方式是，在每次新任务指导书出来的当天下午/晚上，在新北-1楼面🤺，两人一起将指导书从头到尾，逐字逐句翻译、理解一遍，确保双方对每个指令/条件理解相同，然后为每个指令编写一个笼统伪代码来避免后续由于开发时地理空间位置分开，而导致对指令的理解出现分歧。（尽管这样的做法在第二次作业中由于细节零碎且需求更改频繁而惨遭滑铁卢，但单以第一次体验为参照，确确实实能显著提高结对工程后期的开发效率）
结对过程中遇到最大的困难就在第二次任务的后期，具体情况是由于错误的预估了各部分任务的复杂程度导致任务量分配较为不均，以及前期没能完全理解各项指令的要求，本着”走一步是一步“的理论一顿乱炖(无论是单元测试还是代码实现)，造就了最后两天疯狂向各路大佬询问+看issue+压线debug的窘态 (祈祷OO老师和助教看不到
结对编程的优缺点第一次博客已经总结了，不再重复。而通过我们两周的结对体验，我们最大的体会是：针对线下面基和线上合作两种工作环境，要分别采取不同的交流方式，以保证合作融洽且高效的进行。即由于在线下大家面对面，交流的机会更多，这时可以畅所欲言，提出自己各方面的针对项目、队友的意见，这样二人可以当面协商探讨。而线上由于场地因素，许多交流都通过微信聊天框实现，而文字所能传递的信息相较面对面口头会少很多，因此更需要精炼语句，对话时省略掉不需要对方知晓的细节，用"做了什么/哪里存在问题，原因是xxx"的格式精炼概括，将微信中的文本对话当成两个bot间的问答，能更有利于同伴直接获取自己的进展，同时启到记录的作用（类似commit中的注释），效果如下图：
2 紧张刺🤺的互评环节
L To Z
说实话，能熬夜写代码到如此之晚（有一次是到了6点吗，太狠了），你的韧性令我佩服。我在DDL临近时还没完全理清指导书的要求时几乎就要放弃了，但你的坚持也让我重振勇气陪你一起熬夜（虽然说到3点就顶不住了）。不过我觉得你在第二阶段的时候有很多意见都没有说，这不仅影响了我们之间的沟通，还把你自己搞得闷闷不乐。既然是结对，就应该深入地交流，不能因为小问题（当然可能并不小）破坏了结对的氛围。很期待今后仍有合作的机会。
Z To L
仔细一想这并不是我们第一次结对了，上学期证据法学课上也有过合作，总的来讲和你组队体验都很不错，大家都对学习和成绩有明确的目标，这也保障了我们对结对项目都有着责任心，不会出现两人都是”等等党“，都在等对面先急了开始揽活，然后自己能继续摸鱼的诡异情况。
BTW，在结对的过程中我也向你提出了一些意见，希望能对你有所帮助：
- 在针对队友完成的项目做出评价，或者给出自己见解的时候，不要光说”这个不好/这个不对“，而是要同时给出对修改完善项目具有可行性的见解，至少也要说明不好的原因，例如”我认为这个不好，改成...better/这里有问题，因为...“，具体可参考汉堡点评法中的说服(Persuasion)。因为我们是一个项目团队，我们最终的目的都是将这个项目做完，做好，大家的目标是一致的。To be honest，在紧张的开发阶段，如果队友的书写有错误/实现的有缺陷，他更希望听到的是别人对"该如何进行更新/修改"提出建设性的意见，而不是单纯的站在高处评价队友所做的工作的好坏，这样可能会影响到队友的开发热情。
- 在许多时候要更为主动的去给自己安排工作/找事做，而不是等队友来安排。因为在结对项目中我们是平等的，没有所谓的leader（可能有会更好？仔细一想这或许就是所谓的领导力，既能自身掌握全局，统筹安排，还能在白脸红脸间自由切换：同伴失意时加以鼓励，同伴犯错时当面指出纠正）。性格偏外向的我在项目初期阶段可能会作为沟通的主动方并宏观上的分配任务，但到了后期事情越来越多越来越杂，我自己处理起来较为费力的时候，我就很难做到在完成自己任务的同时把控好全局的项目进程，这时就需要你自身去筛查我们的项目还差什么，还有什么漏洞，有就主动去填补，而不是细致到发现一个小bug都要来询问这个bug该由谁来修改，毕竟这是我们的项目，属于我们需要共同维护的”财产“，因此无论是谁发现了问题都应该是要抢着去完善。
最后，需要向你道歉的是，可能由于我属于那种半个急性子又爱面子，不太擅长当面向队友提出意见和要求的人，导致在第二次作业最后的阶段，我看到还有很多问题没解决，线下合作的效率又很低时，还固执的把很多活往自己身上揽。导致自己生了一些闷气，也间接影响到了你，抱歉，这不是一个理智的队友应该做的事，我会努力改正，同时期待下一次更加完美的合作 [orz.gif]。
3 使用的工具-Z同学
IDEA、JUNIT、GIT、GITLab-CI、Ubuntu、微信、Genshin Impact (巧合间发现：原来你也玩...)
4 感想&体会&吐槽-Z同学
第一次结对作业的体验极佳，任务简单+指导书清晰明了，让我们很好的践行了《构建之法》中所说的
结对编程中驾驶员和领航员的角色要经常互换
这不仅避免了长期工作带来的观察力判断力下降，还保证了我们双方对对方书写的代码亲密度达到100%，直接免去了后期测试/debug时的代码阅读难度。
第二次结对作业，emmm，完全就是另一种情况了。
总的来讲，4.5号晚10点DDL结束后，我和我的小伙伴的样子大概是这样的：
（内容过于写实遂打码）
像经历了一场旷日持久战争一样，即使胜利了眼神里仍带着一丝麻木。
可以说助教团队用千变万化的指导书着实让我们体会到了如何应对未来客户飘忽不定的需求，但YYSY模拟的还是太过于逼真了，许多例如CP指令遇到dst、src的文件类型不同时该如何处理没有官方明确的说明，尽管到最后发布了如”不会测试该类数据“的issue，但也无法时空回溯，挽回开发阶段在这些方面耗费的时间。
尽管进行任务时的体验确实有亿点煎熬，But，Every coin has two sides (非套话.jpg)，整个结对项目结束后，回想起大家为了一个目标一起通宵讨论问题+分配任务+捕虫到4点，还是十分充实且收获颇多的。
另外，感谢yyh、wcf、lcy同学和zbm、cookie助教的帮助，解答了我在指令上的N多问题。敬礼、礼毕。
