ふたりの男の禁断の絆の初体験
结对项目第Ⅲ阶段
| 项目 | 内容 |
|---|---|
| 教学班级 | 2021春季软件工程（罗杰 任健） (北京航空航天大学 - 计算机学院) |
| GitLab项目地址 | 2021_Xiaodong_Lu-Pengyang_Xie_pair_work |
| Mokoghost学号后四位 | 3647 |
| duckingss学号后四位 | 3054 |
结对项目实践反思
问题分析
针对前面两个阶段中出现的问题，分析问题的特征、产生的根源和对质量的影响程度；
第一次出现的问题
- 讨论时间过长
第一次结伴作业中，在分析规划方面，我们花费了一个下午和晚上的时间来进行需求分析，代码结构设计，在分析规划阶段就实现了MyFileSystem内部函数的逻辑，在编码阶段就只需要实现File，Dir还有Parser类内部接口即可，编码实现阶段异常顺利，然而这样的坏处在于效率不高，整个开发阶段并行部分很少，大部分时间是串行，而且在规划阶段就将FileSystem类内部的具体逻辑实现也没有必要。不过充分的讨论让我们避免了低级错误和结构问题，提升了我们的代码质量。
第二次出现的问题
- 讨论不够充分
事先没有充分分析指导书，对于很多细节的实现没有仔细思考充分讨论交换意见，甚至导致后期出现需要对结构进行一定规模修改的bug。同时，由于讨论不充分，分工后开发用户系统的同学也无法帮助开发文件系统的同学修补bug或是提供思路，对其实现细节不清楚，编写单元测试时只能黑盒测试。这严重影响了程序质量，造成了大量Debug的时间和对指导书的误解。例如，对于异常抛出的处理，未经详细的讨论定下实现的方式，造成编写此部分的同学误入歧途，构想了许多非必要的简化，实则为后期引入了很多麻烦。
- 出现问题时没有及时寻求帮助
每当产生对指导书的疑问时，总是自顾自地推理，试图通过一己之力解决疑问，浪费了大量时间用于讨论需求与规则。
需求分析收获
总结结对项目中的需求分析实践体会，并分析哪些bug是因为需求分析不足而带来的；
在本次结伴编程中，我们两次任务对需求分析占比不同，导致了完全不同的结果。第一次细致的需求让我们在编码阶段如鱼得水，第二阶段不细致需求分析则让我们在编码和测试阶段痛苦万分，特别是由于没有讨论清楚mv，cp的不同复制，修改行为，异常抛出如何设定，软硬链接在重定向问题，我们在这几个函数上花费了大量的时间，属于邹欣老师书上说的写了再改的模式，花费了我们大量的时间成本。
综合两次经验，我们总结出需求分析的几个经验。需求分析需要捋清楚具体的行为，在接口固定的情况下，对于复杂函数可以通过尝试先编写单元测试的方式进行需求分析。同时，我们认为需求分析中需要和架构设计应该是能够耦合在一起的(至少对于本次作业而言)，因为需求文档中各个看似无关的需求可以映射到某一个架构上，例如本次的软硬链接中，如果在需求阶段把软链接看作指向索引的索引(即，存储的是字符串)，硬链接看作指向文件的索引，那么在讨论重定向的问题时就会轻松很多。
架构设计体会
总结结对中的架构设计实践体会，描述通过改进设计来提高程序的性能改进的思路和方法，并分析哪些bug是因为架构设计不足（特别的，需求变化）而触发的bug；
完成第一次作业时充分的讨论让我们整体的架构鲁棒性较好，第二次作业时由于某些函数进行了"写了改"的模式，文件系统架构有些不足，由于把把本该在FileSystem级处理的函数，放入了Dir类中，导致了cp和mv的许多bug。
两次设计中，在架构设计方面，我们对于软件设计中的设计原则有了更加深刻的理解。特别是职责单一原则。在提高程序鲁棒性方面，我们通过在不同的类中实现不同方法的方式，来讲错误进行了局部化，同时编码复杂度也得到了指数级下降。对于程序优化方面，由于涉及到全局优化，我们通过人工分析位于某一层级的方法中的共有模式，将他们提取处理出来到一个函数内，再对该函数进行优化。比如对于filewrite,filetouch,fileappen都有同样的检查存在->不存在->创建的模式，我们写了一个filemodifyMode函数,并对这个函数逻辑进行部分优化。对于架构的另外一个优化层面，则是优化底层函数，比如各个类内部实现的find函数，对其进行一些细节上的修改进行优化，或者在共同父类中进行优化（在父类中优化为设想，没有实际实现）。
进度、质量和沟通管理实践体会
总结结对过程中的进度、质量和沟通管理实践体会，并分析哪些bug是因为两个人的理解不一致而导致；
实际上，在本次结对作业中我们对项目进度、质量和沟通的管理是缺失的。由于不重视管理中的规范，我们没有记录开发流程，大部分问题与讨论也仅停留在口头，过程中产生的log文件往往只有写它的人才能看懂，并没有什么规范（实际上做的最好的规范是Javadoc，我们在方法前书写了数百行Javadoc，为我们的开发、code review都提高了效率）。
对于进度的把控十分崩坏，没有明确每一次开发的目标，这导致了多次意义不明的熬夜，时常陷入低效的漩涡，一个人埋头开发，另一个人却处理着并不要紧的工作（例如写测试，完全可以不熬夜完成）。
代码质量的把控在明确的code style下看似能够轻易地落实，实际上缺乏沟通使得一些地方编程思路不一致，同时缺乏统一的规则与详实的记录，让不同时间的不同开发者难以统一。
缺乏沟通也降低了本次开发的效率，很多时候同伴的“失联”让另一位开发者不知所措。没有经过充分的独立思考时常也会造成低效的沟通，问出“奇怪的问题”，实际上可能答案就蕴藏在指导书中，却要让负责另一部分的同伴花费几分钟寻找解答。
结对项目建议
提出建议：根据三个阶段的结对项目的实践经验，对如何更好的实施和管理结对项目提出自己的建议。
- 充分的讨论
无论是分析需求、明确规则、讨论架构，还是确定分工、分配时间、划分成果，充分交换意见都是合作项目的必须，没有达成一致的意见，无法拥有良好的结对体验。
- 明确规则
开发中的不一致几乎都是由于缺乏统一的规则。结对项目的代码风格，设计流程，程序架构、分工配合以及时间安排，都应该在开始时定义好。
- 详实而易读的记录
开发过程中看不懂之前写的或是别人写的代码实在是一件很痛苦的事。之前修改了哪些、为什么修改，讨论好的设计架构、实现方式，对需求的解读等等，这些全部应该详细地记录下来，同时需要让双方都能读懂不产生歧义，虽然在记录时可能消耗时间，但是在开发过程中一定能提高效率，降低代码复审的难度。
- 清晰的目标
没有清晰的目标可能会导致无意义的熬夜，也可能会导致低效的开发、单纯浪费时间。确定每天要实现的内容，明确要达到的目标可以帮助开发者心里有数，避免开发时的迷茫。
PSP 规划
整个项目的总PSP：
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 25 | ~25 |
| · Estimate | · 估计这个任务需要多少时间 | 25 | ~25 |
| Development | 开发 | 1360+890+90 | 2190+1205+90 |
| · Analysis | · 需求分析 (包括学习新技术) | 300+240+10 | 180+180+10 |
| · Design Spec | · 生成设计文档 | 30+30+5 | 0+30+5 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 10+10+15 | 120+5+15 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 10+10 | 10+30 |
| · Design | · 具体设计 | 300+60 | 480+320 |
| · Coding | · 具体编码 | 500+360+40 | 600+460+40 |
| · Code Review | · 代码复审 | 60+60+10 | 60+10 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 180+120+10 | 740+180+10 |
| Reporting | 报告 | 120+60+30 | 150+90+30 |
| · Test Report | · 测试报告 | 30+30+10 | 60+30+10 |
| · Size Measurement | · 计算工作量 | 30+20+10 | 30+30+10 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 60+30+10 | 60+30+10 |
| 合计 | 1490+960+130=2580 | 2350+1305+130=3785 |
CI体验感想
通过这次结对编程，你对CI的使用体验如何？你对这一工具有何认识？
这两次作业中，我们使用CI进行了自动化评测，自动JUnit测试和测试覆盖率导出。我觉得CI是一个非常符合工程思维的东西，他将打包测试等流程进行了自动化。一次配置，就将团第成员从某些每次都要进行的繁琐流程中解放了出来，是一种一劳永逸的方式。然而本次CI使用还是有些不足，每次使用的单元测试时都需要进行包的安装，花费了许多时间，如果以后将自己的将runner换成自己的服务器，体验会有进一部提升。
结对编程感想
描述你们结对的方法、结对过程中遇到的困难与收获，结合自己的结对经历，说明结对编程的优点和缺点，分享可以推广的结对妙招。
结对过程中，我们配合默契，讨论充分，对于同一问题产生不同的看法总是能通过“桥梁”或是“说服”的方式达成一致，期间有思考，有探讨，有妥协也有对对方奇思妙想的赞叹。
结对编程增强了我们的工程能力，尤其是项目合作的能力，同时有效提升了代码质量，两个人总能考虑地更周全，有头脑风暴思路也产生地更快。
然而结对编程对项目的质量管理、成员的沟通能力都有更高的要求，相对于一个人写代码安静的环境，沟通可能会对对方产生干扰。同时，如果没有充分的磨合，时间开销可能反而比一个人开发更大，观察发现，班级里许多编码时间比我们更短的项目，开发任务往往在由一个人承担。
评价你的队友，使用汉堡点评法评价你的结对伙伴，务必给TA 提改进意见。
Mokoghost➡️duckingss：
duckingss的码力和动手能力很强，一边讨论一边就能开始写，我实在佩服👍🏻。参与过OI和ACM的duckingss知识面也十分广，不仅对于自己未来的目标明确，而且已经实实在在地走出了坚实的步伐，是一个实干家！大行不顾细谨，duckingss有时候会疏忽一些细节，例如代码规范、代码结构，有些竞赛画风，不过经过我的一两次建议后就立马能写出工整而规范的高水平代码，其谦虚、细致、及时采纳他人意见如此，不可不谓之有才。
duckingss➡️Mokoghost：
Mokoghost的思维条例非常清晰，能够把很多例如软硬链接结构的复杂的问题考虑清楚，有丰富的管理和科研经验，也非常具有团队合作精神,能够及时切换团队身份，进行救火。但是作息安排可能有点不太健康，希望能好好注意一下，有一个健康的身体才能走得更远，才能更好地展现Mokoghost的才华。
描述在本次结对编程的过程中，你们使用了哪些软件工具，是如何应用于实践的。
本次结伴中我们使用了IDEA+code with me，git，maven+cobertura三款软件工具。IDEA+code with me用于在线和远程协同开发。git用于版本管理，记录每次提交信息等功能，我们通过git的log来进行复盘。通过使用maven+cobertura进行测试单元测试，引入依赖包。
描述通过本次结对编程的感悟和体会，对本次作业的有哪些想吐槽的，觉得本次结对作业内容可以在哪些方面做出改进？
详见结对项目第一阶段总结与对软工课程的拙见的正文与评论区。
