| 项目 | 内容 |
|---|---|
| 这个作业属于那个课程 | |
| 这个作业的要求在哪里 | |
| 我在这个课程的目标是 | 团队协作，利用软件工程的思维和方法开发出一款具有实用价值的软件 |
| 这个作业在哪个具体方面帮助我实现目标 | 结对编程，反思总结 |
结对项目实践反思
（1）针对前面两个阶段中出现的问题，分析问题的特征、产生的根源和对质量的影响程度；
在两个阶段的结对编程实践中，我们出现了如下问题：
-
需求分析时间长但未取得满意成果
在第一阶段的结对编程中，我们在需求分析和架构设计方面花费了大量的时间，期望像PSP流程中工程师团队那样，在需求分析多花点力气，在编码实现就能省点力气。可是，虽然我们在设计阶段尽可能地将很多细节问题都考虑全面了，在具体设计阶段却没有达成共识。有很多问题与细节在具体编码的时候才能想的清楚并敲定。比如说文件系统中查找路径的算法，对于每一个方法来说，该算法的变体都需要用到，但具体逻辑在细节上有所不同。在前期，我们暂定为不封装函数，可是在编码的时候发现封装函数才是正确的选择，这造成了长时间的需求分析的成果大打折扣。如果我们在具体设计阶段也能结对一同工作的话，就可以迅速敲定方法级的规格设计，同时编码测试了。
-
适度减少前期的需求分析时间，但应对需求变化不够充分
在第二阶段的结对编程中，我们吸收了第一阶段的教训，没有在需求分析和设计阶段花费大量的时间扣细节，而是更多在整体的框架上达成共识，将实现的细节交由编码部分处理。
但是由于这次作业需求变化较快，加上由于课业原因该阶段调整到相同时间结对的时间减少了，而我们在一些细节方面讨论得不够充分，比如对于异常的抛出顺序等，导致该部分出现了很多异常抛出顺序，存在异常和非法异常抛错等问题。
（2）总结结对项目中的需求分析实践体会，并分析哪些bug是因为需求分析不足而带来的；
第一阶段的结对编程过程中，我们进行了与任务难度不匹配的长时间的需求分析，在这个过程中，我们两个人互为领航员和驾驶员，相互引导、纠偏，在需求分析方面完成比较全面。在之后的阶段，由于需求分析阶段花费了很多时间，产生了一定的厌倦心理以及自信，于是较少关心指导书的需求，最终犯了一个比较低级的错误——文件的长度规定。但总的来说，需求分析完成度是不错的，也给后面的工作推进带来了好处。
本次项目中对于需求分析不足而带来的问题最为严重的就是在第二阶段，对于一阶段代码的修改需求。典型的包括，报错信息的完善，对于路径中出现链接重定向的处理等。最后测试出了很多包括报错了错误，项目一中的方法对于链接的处理出现了问题等在内的问题。我们在进行项目第二阶段时，需求分析重点放在了对于新加入的方法的处理，而忽视了对于原有方法的修改，导致后续编码过程中的不完善。
（3）总结结对中的架构设计实践体会，描述通过改进设计来提高程序的性能改进的思路和方法，并分析哪些bug是因为架构设计不足（特别的，需求变化）而触发的bug；
我们在结对的过程中，需求分析和架构设计是一起进行的。结对编程设计架构的时候，通过两个人之间的交流，可以得到一个更为完善的架构。两个人经常会对于同一个问题想出多种不同的解决方案，比如对于容器的选择，某些属性的处理方式等。在本次的作业中，我一开始本来是想用list来存储子目录和文件的，但是另一位同学提出因为文件名是唯一的，用文件名做key的map来存储会更好，更能符合经常增删的操作，最终我们也是这样设计的。
此外，对于有些函数共有的结构，比如根据路径查找，创建文件和目录等，本来在设计阶段我们认为由于每个函数的实现都有一些细微的差别，于是便不抽象出相应的方法。但在实际的编码阶段，发现提取共有方法后能大大简化代码，于是还是实现了。
本次项目中由于架构设计不足而触发的bug，最明显的就是对于文件和目录的大小的处理。我们本来的架构设计是在文件修改大小时递归修改该文件对应的所有上层目录大小。但是在第二阶段加入了硬链接后，这种方法就会出现不同步的bug，所以只能修改为在读取文件或者目录大小时递归向下查找。
（4）总结结对过程中的进度、质量和沟通管理实践体会，并分析哪些哪些bug是因为两个人的理解不一致而导致；
在进度方面，我们只有大致的进度管理，大概就是说一下周几之前完成什么工作之类的。不过实际上还是有没有按时完成导致晚上熬夜的情况发生，可能这是我们在交流的时候没有考虑其他事项的原因。
在质量方面，由于我们提前对于接口的设计，两个人在编码的时候没有出现太多不一致的情况，同时两人的交接部分也较为出色，这也可能是结对编程过程中两人共写一份代码的功劳。这也让我再次体会到了提前设计的重要性。
在沟通方面，我们两人之间的沟通基本都十分即时，大部分情况下都能即时完成对于一些代码和问题之间的交流。
在本次过程中出现的由于两人理解不一致的bug，很大程度上是来自于issue区。可能有时一个人没有看到issue区中相应的内容，就会对某些细节产生疑问，如果另一个人此时没能即时解释清楚的话，就会导致无法理解某一段代码的内容，从而产生一系列问题。
（5）提出建议：根据三个阶段的结对项目的实践经验，对如何更好的实施和管理结对项目提出自己的建议。
-
为需求分析和架构设计留出充分的时间
需求分析和架构设计花的时间都是在为后续的编码阶段省麻烦。但是也不能在上面过于扣细节，得到大致的框架即可。细节问题后续肯定要再改，一开始设计的过多反而会自缚手脚。如何在结对编程中把握分析与设计的时间和工作进度，如何在团队协作中高效地完成
`analysis&design的工作，是一个值得探讨和研究问题。就像《构建之法》中提到的效能分析，如果过早进行或者纠结，将会事倍功半。 -
充分测试
结对编程最后的阶段，两人一定要将需求从头到尾的每个细节都走一遍，保证一些细枝末节的地方没有问题。这次作业我们就是在这方面做的不足导致强测出bug。
-
科学的注释
如果某段代码不是在两人同时在的情况下编写的，一定要做出充分的注释保证另一个人能够看得懂。同时，另一个人在走查这段代码的时候也能根据注释发现相应的逻辑问题。当然注释只需要标注代码“做了什么”以及“为什么这么做‘”和值得注意的点。
CI体验感想
通过这次结对编程，你对CI的使用体验如何？你对这一工具有何认识？
通过这次的结对编程，我感觉gitlab CI这种持续部署的工具非常契合软件工程开发的，他能让每个成员省略掉一些每次都要做的繁琐的操作，比如打包测试、测评等，能够以一种类似自动脚本的方式实现一劳永逸。不过CI还存在一些不完美的地方，比如对于yaml出错时的反馈不足等。
结对编程感想
我们在第一阶段过程中只有在一起结对设计，后续一人负责编码一人负责测试。第二阶段才开始了真正的结对编码。结对过程中遇到的最大困难可能还是后续两人理解不同步的问题，这很大一部分来自于需求的不断更新，但是这能够通过充分的及时沟通来解决。在结对过程中最大的收获就是知道了需求分析和设计架构的问题，以及从另一个人的角度来看的话能更容易发现代码中存在的细节问题和逻辑问题。
结对编程的优点是能够集合两个人的力量，提升代码的质量，适合处理一些需要高速运转、对技术要求高、失败代价高的任务。但缺点是结对编程的要求较高，一是对沟通的要求较高，结对编程需要一起同步工作，开发与评审同时进行，同时推进，两人全程深度参与，多核处理同一个任务。这对双方的时间协调、沟通都提出了较高的要求。对于有不同课业任务/实习/考研安排的大三学生来说，如果面对一个比较复杂&需要快速开发&需求不断变化的任务来说，协调到统一的足够的时间进行结对编程就是一个难题。
（2）评价你的队友，使用汉堡点评法评价你的结对伙伴，务必给TA 提改进意见。
3075——>3407：3407同学在思考问题的时候能够在细节上考虑很多，检查代码的时候也能认真的考虑每一个细节，找到很多之前由于马虎留下的错误，同时也能即时地对问题做出反馈。但是我感觉他在编码的效率上可能还有待提升，这也导致了很多时候他会熬夜工作，养成不好的作息习惯。希望他能更合理高效地完成工作，养成良好的作息习惯，身体才是革命的本钱。
3047——>3075：3075同学反应快，脑子灵，编码高效，能很快想要基本解决方案并完成基本的任务；不仅能力强，而且脾气好，有段时间其他事情很多导致在结对编程任务中投入时间不太够，他都主动替我完成了一些工作量。给个赞！但我认为他在细节方面考虑不够全面 ，可能快速编码引入了不少bug，希望他能在测试和架构设计上花一点时间，编码完了少打点游戏。
（3）描述在本次结对编程的过程中，你们使用了哪些软件工具，是如何应用于实践的。
我们主要运用了idea+code with me，gitlab-CI，maven+cobertura+Junit工具。通过code with me，我们完成了第二阶段的远程结对编码，实现了一人写代码另一人作为“领航员”的编码模式。gitlab-CI则是用提交和管理我们的代码，用于代码的同步。并且通过相关的CI配置在测评机上完成了相应环境和jar包的安装。maven+cobertura+Junit则是我们编写java工程并进行单元测试的工具，利用相关的内容完成了单元测试同时导出了覆盖率相关信息。
（4）描述通过本次结对编程的感悟和体会，对本次作业的有哪些想吐槽的，觉得本次结对作业内容可以在哪些方面做出改进？
对于整个结对编程作业，我体会到了完全不一样的一种工程的完成方式。通过两个人的视角，我们完成了更高质量的代码，发现了很多一个人的时候只能靠最后测评机才能找到的细节bug（可能只是我单纯的不会测试而已）。总之，结对编程不只是对于编码能力的锻炼，也是对于与他人之间的交流和合作的一次锻炼，这两项能力也极为重要。