[I.3] 个人作业：结课总结

21371163-洪陈天一 2024-06-30 20:26:04

项目	内容
这个作业属于哪个课程	2024年北航敏捷软件工程
这个作业的要求在哪里	[I.3] 个人作业：结课总结-CSDN社区
我在这个课程的目标是	学习敏捷开发的思想，学会组织团队，开发出一款有趣的软件
这个作业在哪个具体方面帮助我实现目标	总结软工课的体验与收获

问题解答

个人作业：阅读和提问-CSDN社区

问题1 单元测试必须由最熟悉代码的人（程序的作者）来写吗？

在结对编程中，单元测试的编写让我理解到了程序作者

但是对于其必要性，由于我们的软工课程项目为不适宜单元测试的游戏，因此并没有在实践中得到一些结论，因此我尝试询问chatgpt并得到了以下结果：

单元测试并不一定必须由最熟悉代码的人（程序的作者）来编写。尽管程序的作者通常最熟悉代码的细节，能够更有效地编写出针对特定功能的测试用例，但也有很多情况下，其他开发人员、测试人员或专门的质量保证（QA）团队可以编写单元测试。以下是一些考虑因素：

代码质量和覆盖率：无论谁编写单元测试，最终目的是确保代码的质量和覆盖率。如果其他开发人员或测试人员能够编写高质量的单元测试，同样能够达到这个目的。
团队协作：编写单元测试可以促进团队成员之间的协作和知识共享。让其他开发人员参与单元测试的编写，可以帮助他们更好地理解代码，提高整个团队的技术水平。
客观性：有时候，程序的作者可能会对自己的代码有偏见，认为某些部分不需要测试。让其他人编写单元测试可以提供一种客观的视角，更全面地覆盖各种可能的测试场景。
测试驱动开发（TDD）：在TDD中，测试用例通常在代码编写之前就已经编写好。这种方法强调了测试和开发的分离，鼓励开发人员在编写代码之前就思考如何验证代码的正确性。
工作负载分配：将单元测试的编写任务分配给其他团队成员，可以帮助程序的作者专注于更复杂的功能开发和问题解决。

综上所述，单元测试不一定必须由最熟悉代码的人来写，关键是确保测试的有效性和代码的高质量。

其中部分与我的观点比较接近，代码的作者可能陷入自己的思维误区。而另外的内容也启发我思考在测试用例编写上的工作分配的问题。

问题2 结对编程是否能不断复审，及时发现和解决问题

我一向是不理解不赞同结对编程的，而在结对编程后更加认同了我之前的看法，对于不好的结对完全无法完成不断复审的过程，而对于相近水平的结对，效率也显著低于独立工作，同时在不完全理解整体与局部思路的时候很难发现问题。

问题3 如何才能站在用户的角度看问题

与用户充分沟通，理解用户所想。

问题4 如何高效运用图形建模工具

软工过程中，发现了在需要时合理使用时序图的价值，~~弥补了OO给我带来的UML图完全没用的印象，~~比较复杂的逻辑可以通过时序图等图形建模方便地与他人分享、沟通，因此能够熟练使用图形建模工具的人应当可以有效提高团队工作效率，不过这也分人吧。

问题5 “迷思之五：要成为领域的专家，才能创新”

非问题，保持原有对书中内容质疑。

知识点

需求：对于游戏的需求调研其实就是玩家喜好的调研，而作为一个相较于销量其实更看重制作者想做些什么的独立游戏来说，需求调研其实没有那么重要。
设计：模块化设计，明确需求，完善文档。
实现：不知道这部分有什么知识点（），但是一个可维护性高的实现对于后续的迭代开发至关重要。也许学到了的是 Code Review 的方法吧。
测试：测试很重要，尤其是在不同条件的设备下进行测试（不充分测试所以展示出大锅）。但是游戏可能也依赖于玩家反馈来进行进一步的修复。
发布：对于游戏，在发布时配以视频与完善的介绍能够极高地提升玩家尝试的兴趣，但由于我们软工课工期不足显然无法完成（而且也不是做宣传视频的课程）。
维护：我还在维护哦。作为独立游戏，其实维护的需求较低，理论只需要修修bug就好了~~而网站维护需要考虑的就多了~~。但是我还在进行一定的平衡性调整工作，不过相比其他还是要少很多维护相关的。