2021S软件工程——结对项目第三阶段

2021春季软件工程（罗杰任健）

1020 1169

1 实践反思

1.1 问题分析

两人习惯不一致
没有具体制定时间节点
写完代码才开始“应付”测试
代码架构不清晰

以上的这些问题导致我们这次项目（尤其是第二阶段）实现得并不算太好，在后期出现了赶工、代码一团乱麻的情况，也导致了一些BUG的出现。

1.2 需求分析实践体会

在此次项目的需求分析中，我认为我们做得还算不错，对指导书基本没有错误理解。有模糊的地方，也立刻沟通交流、查看已有issue、询问助教（客户）。但是在对指导书进行阅读以后，我们并没有将用户需求，转化为设计文档或相关的注释，这导致我们实现时总是要重新回顾需求，浪费了一些时间。

1.3 架构设计实践体会

在架构设计方面，我认为我们做得一般。在第一阶段中，虽然我们花费在设计上的时间也不多，但是两人还是对架构达成了一定共识：树形文件管理结构。并且实现中，我认为还是基本遵循了这个架构的。

但是在第二阶段，加入了用户系统，我们没有考虑好架构，在文件系统与用户系统交互时就显得手忙脚乱，实现得并不优雅。同时也导致了一个BUG，在某个用户系统的方法中，没有增加命令条数，导致了错误。

1.4 进度、质量和沟通管理实践体会

我认为在这一方面，我们的团队做的不是很好。在第一阶段中体现得还不是特别明显。在第二阶段，我们没有明确时间节点以及质量要求。在项目后期，为了赶上ddl，我们的代码为了完成指导书的任务可以说是“无所不用其极”，测试也不够细致，甚至有些部分只是为了达到相应的覆盖率。赶工+应付覆盖率导致了测试十分不全面，最后也直接导致了项目中出现了低级的BUG。可以说，在第二阶段后期写出的代码质量惨不忍睹，只能在最低限度完成任务。

沟通管理方面，我认为我们虽然没有遇到较大的分歧而导致BUG，但遇到不同理解时，我们会谁也说服不了谁，浪费了一些时间。好在最后直接询问助教，达成正确的一致意见。

1.5 自我建议

认真写设计文档！

这次项目中，我觉得吃了不认真写设计文档的大亏。上手指导书后，几乎没有怎么好好思考，就直接开始编码，导致许多细节没有注意到，后期修改时，把代码改得一团糟，并且在测试的时候也不好下手。
多和队友沟通自己的想法

这是我很大的一个问题。我总是有什么想法，没有跟队友说明就闷头修改了代码，导致队友看代码时可能一头雾水。这毕竟是个团队项目，不能当“独行侠”。
制定时间节点

两人结对，也算是一个团队了。我感受到团队很需要制定好每一项任务的时间节点，不然就会导致“工期”越来越紧凑，最后甚至需要赶工。如果在一开始就合理制定时间节点并严格遵守，我想能够很大程度上提高团队效率与工程质量。

2 CI体验感想

在这次项目中，我第一次在真实场景使用了CI。CI的.yml文档格式学习起来较为简单，所以还是挺好上手的。虽然在课程中使用CI好像只是换了一种方式提交代码评测，但是我觉得在未来的实际工程中，CI是可以发挥很大用处的。比如先写好大量的测试用例，写好代码后只需要直接提交就可以进行测试，想一想还挺“酷”的。

让我印象很深刻的是，在写好代码以后，我push到gitlab上，然后就跟舍友一起去吃饭，吃饭途中掏出手机看了一眼，说：“bug都改好了”。舍友特别惊奇地问：“你在手机上也能提交吗？”这种全平台可查看的特性，大大地便利了开发者。

当然，我也认识到我只不过是刚刚接触了CI。像如何用相关工具提交自己的覆盖率与相关信息，我是请教了同学才知道。我认为CI还有许许多多强大的功能等待我去探索，相信它能够进一步提高我的开发效率。

3 结对编程感想

3.1 结对过程

我们一开始是选择了线下共同进行开发，因为认为当面交流会有更高的效率。但是由于对结对编程的理解不够深入或者有偏差，反而在线下结对的过程中，总是纠结于细枝末节的地方，反而降低了开发效率，一个晚上基本没有什么产出。

由于我个人的编码习惯，再找我们共同的时间有些困难，我就熬着夜把大致的架构完成了。然而，这样反而导致了队友要花大量的时间阅读我写完的代码，无法继续推进。

我与队友不在一栋公寓楼，上课时间也是“错综复杂”，出门找地方结对实在太浪费时间。后来，我们选择了使用腾讯会议进行结对编程，开启屏幕共享，我认为效果与当面交流相比并不差。所以后期我们选择更多是以腾讯会议+微信交流的方式线上合作。

在Debug的过程中，我们也遇到了一些困难。一个人写代码的逻辑，另一个人不是那么容易理解，所以DEBUG时，发现BUG的人不一定能第一时间解决，要等待写代码的那个人来修改，这也很影响效率。

不过，在结对过程中，两个人分别读指导书后交流，能够注意到很多细节的部分。相比我之前一个人做OO总丢三落四，这次结对“疏忽”的情况少了许多。

总的来说，结对编程在初期，需要两人磨合与适应，这段时间可能开发效率会$1+1<2$。如果两人达到了一个“和谐”的状态，我想不仅能够更多地关注到细节，也能够提高开发效率。

3.2 对队友的评价

在本次结对中，我们两人都想要认真地完成好这一个阶段的项目。在与队友沟通交流的过程中，他给我留下了不错的印象，在合作的过程中我们也没有出现特别大的分歧与矛盾。

对队友有以下三方面的建议：

对项目所需的工具链多作一些了解
提高编码水平
及时沟通交流进度
注意任务时间节点

相信他在完善了这些方面以后，会是一个更好的队友。

3.3 使用工具

本次结对编程中，我们主要使用Git进行版本管理。写完代码就push到仓库，并在commit中说明自己完成的任务。队友需要push前pull最新代码，可以实现很好地并行开发。

我们还使用了微信、腾讯会议等线上交流工具，便于更加及时的沟通交流，甚至部分替代了面对面的线下交流。

3.4 总结感想

本次结对编程，我很好地熟悉了CI工具链，体验了两人结对编程的过程，进行了一定的磨合。

这次结对编程对我来说是略带痛苦的，两人的编程水平、可用时间、代码习惯都有所冲突。然而我们没有进行前期的磨合，直接开始在项目中磨合，导致了许多问题。我觉得可以添加一个小队磨合期，早一些让大家与队友进行交流，甚至增加一个不计分的简单项目用以磨合两人、发现问题。