[北航2022软件工程] 提问回顾与个人总结

一、提问回顾

学期开始的时候，我在快速阅览课本之后提出了一些问题。经历了一学期的实践，对其中的一些问题有了新的理解。
1. 关于单元测试

对于主流的开发框架，都有现成的UI测试工具。比如针对Unity的UI测试工具就有AltUnityTester、AirtestProject等。
开发过程中，应该将UI测试与单元测试放到同一地位。因为在开发了新功能或者修改一些bug之后，很可能对已经测试通过的功能引入新的bug，应当借助自动测试工具每次对他们进行回归测试，减少错误的发生。
2. 关于分工

文中提到的问题我们在实际开发过程中确实遇到了。在多人开发的alpha阶段中，团队共有8人，分了四个人开发客户端，两个人开发后端，一个人测试，一个人写网页。然而四个人开发客户端的进度完全赶不上两个人开发后端的进度，因此两个开发后端的同学就没什么事做。
进入beta以后，为了解决以上问题，将一位后端同学纳入到客户端的开发工作中，才勉强赶上一个后端的开发速度。
3. 关于杀手功能

从众多需求中寻找杀手功能是很依赖灵感的东西。在团队项目确定设计的时候，所有的小组成员和中传的同学聚集在一起进行头脑风暴，用数量提高找到好的设计的概率。
4. 关于设计文档与代码

很遗憾，经历了一学期的学习仍不能对这一问题做出解答，因为开发的过程中由于代码量较小，并没有采用先设计再编写的形式，而是确定UI设计稿以后直接开始写。
这样确实遇到了很多问题。比如在开发好友界面的时候，涉及到的几个类和资源的互相调用关系，我在脑子里自己设计好了就自己实现了。结果后来小组成员打算复用的时候，花了一晚上的时间自己去搞明白它们之间的调用关系。如果我能在实现以前先完成纸面上的设计并同步到团队设计文档，小组成员的复用过程就会变得简单很多。
5. 关于初创团队以怎样的思路规范自己的源代码管理

实际操作过程中发现，git能解决书中提到的大部分问题，唯一比较棘手的问题是冲突问题。由于unity有许多配置文件是自动生成的，因此两个人修改同一事物时很可能产生冲突。一旦产生冲突，就会导致这一整个部分崩溃而无法简单的选择其中一个人的改变，因此就需要产生冲突的这个人抛弃掉自己本次提交的所有内容，pull下来以后重新再写一遍。
对于这个问题也没有很好的解决思路，只能在改某个可能别人也会改的地方之前就在群里说一声，我要改某个地方了，大家不要动。
二、学到的知识点

1. 需求阶段

我们在需求分析阶段采用了NABCD模型，客观的分析了我们要做的项目——高校元宇宙的必要性、可行性、同类产品比较等。通过一个系统客观的需求分析，我们树立了对于要做的项目的信心。
2. 设计阶段

在设计阶段，我体会到了软件原型图的重要性。我们通过小组讨论，与中传的同学确定了整个软件划分为哪几个部分，然后共同实现原型图的设计。同时借助工具，实现了预览与跳转的逻辑。
通过原型图设计，我们能尽可能早的讨论各个部分的设计细节，使我们在实现阶段能够全心全意的投入编码的工作中，而不需要费心思一遍写代码一遍进行设计。
3. 实现阶段

我们团队使用腾讯的Coding平台进行团队协作，进行进度管理、任务分配、文档管理等工作。每次开完例会后，由PM总结每个人的任务，并通过Coding平台进行分配，同时设置截止时间等要求。这样减轻了思考“接下来要做什么”的时间，使每个人在平时能全心投入到工作中。
4. 测试阶段

我们团队实现了开发与测试分开进行。平时工作时为了加快功能的实现，可以不考虑设备适配、极端情况等，而这些问题放到发布前的测试阶段统一进行。发现一个问题，就用coding分配一个缺陷，集中时间和精力将问题一次性解决。
5. 发布阶段

持续部署是我们团队的一个遗憾。由于是以app开发的形式，不能像web端或小程序一样实时更新。而unity想要实现”更新“是很困难的，我们没有办法发布一个新版本，就自动为用户更新，而必须让用户手动卸载旧版本、下载新版本、安装新版本。这也是未来这个项目要解决的一个重要问题。
6. 维护阶段

由于上面提到的持续部署问题，产品发布了，就只能通过下一词发布产品来”维护“。能够实时修改的只有后端请求部分。这一阶段我们会不断收集用户的反馈，同时对用户的实际使用情况做出分析，在下一个版本中统一解决。
三、个人总结

本学期的软件工程课让我收获了很多。最开始我并不知道几个老师的软件工程方向不同，就选了吴际老师的课。上了第一节课才知道吴际老师主要是嵌入式方向，对比一下，还是罗杰老师的敏捷开发更令我感兴趣，这边也有熟识的朋友，于是就来罗杰老师这边了。
最开始的结对编程很有趣，“结对”这一概念我是第一次听说，在实际体验过以后，感到确实是很有效果。两个人一起思考的速度要远大于一个人的速度，编写代码时另一个人也能很及时的指出一些低级错误和代码规范问题。然而，由于时间问题，两个人无法经常拿出一块大的时间凑在一起写代码，而一个人自己写反而可以利用各种小时间，因此大部分的代码还是两个人分别完成的，有一些脱离了结对编程的初衷。或许这一方式更适合于全职上班的程序员，学生阶段有些力不从心。
之后的团队项目也很有挑战性很有趣，课程组规划了详细的路线，用一篇篇博客指导我们团队的工作顺序，实现了“在做中学”。团队合作的困难之处从最开始的选题阶段就体现出来了。我们是8个人的小组，同时又和中传那边进行合作。由于不是在公司里，也没有上下级的服从关系，因此当意见出现分歧的时候就只能靠投票来解决。在最后一次的小组会议中，大家推诚布公的交流了彼此的优点与缺点，看到了别人眼中的自己，收获满满。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！