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

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工具链,体验了两人结对编程的过程,进行了一定的磨合。

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

posted @ 2021-04-08 14:24  WilliamHuang  阅读(34)  评论(4编辑  收藏