个人作业 I.3 结课总结

[21371190-谢卓然]

项目	内容
这个作业属于哪个课程	2024年北航敏捷软件工程社区-CSDN社区云
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	了解熟悉敏捷开发的方法论，学习团队合作，并通过实际开发产品来实践
这个作业在哪个具体方面帮助我实现目标	总结课程实践中的经验与教训，更好地掌握敏捷软件工程能力

个人作业 I.1 阅读和提问

一、以前提出的问题

1. 单元测试

有时很难确定应该在什么样的粒度上进行单元测试。如果粒度太小，那么测试往往起不到效果；如果粒度太大，要编写测试逻辑又会变得十分复杂。要怎样确定单元测试的粒度呢？

单元测试的重要性并非是在于对粒度的确定。在敏捷开发方法中，单元测试通过集成测试（CI）进行回归测试，防范新推送的代码破坏之前的功能，是一种在开发过程中非常重要的辅助检验的方法。除此之外，敏捷开发讲究最小可用快速交付，在每一个完成的模块上加入单元测试，也是一种保证最小功能集可用、设计有效的良好方法。

2. 为“未来”而做的架构设计

经常陷入可拓展的方向最终并没有用到，需要拓展的功能又没法很方便地集成到原有代码中的问题，等于可拓展的设计就白白浪费了。如何更有效地考虑“场景”呢？

依然没有想得特别明白，只能说架构设计从来都是一种trade-off，谁赢谁输，看天赏脸。我们只能尽自己所能设计出符合当下需求的架构，并作限制在一定程度内的扩展支持。在这一方面，或许经验更有话语权。

3. 分工与合作

我想，对于这样的软件可运行与否的检查，应该是团队共同的职责。然而，如果项目过大，不可能让每个人都把所有的功能都用一遍，这种时候又该如何分工呢？

测试人员这一职位的设置，在我们的项目开发中起到了很重要的作用。即使可以要求团队成员都具有一定的责任心和热情，对项目产生的问题十分关注，也仍需要安排专门的测试人员进行测试。这一安排通过某种激励，微妙地改变了项目成员之间的关系，有助于实现项目交付质量的稳定。

4. 结对编程

如果两个人完成同一项工作，甚至轮流进行设计，那么不会导致设计很乱、没有一个一以贯之的思想吗？这不会加大维护难度吗？要如何解决这一问题呢？

在深度体验了结对编程后，我认识到结对编程解决这一问题的办法是频繁的沟通，特别是设计（编码前）和编码中的沟通。编码前的沟通有助于令对方了解你的设计思想，并从另一角度思考你的设计的合理性与必要性；编码中的沟通有助于交流编码技巧，探索更加合适的实现方式，并时刻检查可能出现的编码错误。这样一来，二人形同一人，二人的开发思路是经过沟通而保持一致，或至少是能够相互理解的。这样，便能发挥结对编程的优势了。

5. 何时重构

什么时候该重构？

什么时候该重构？

二、实践中学到的知识点

1. 需求阶段

确定需求不是一件容易的事。要考虑清楚产品的目标群体是谁，以及目标群体可能的需求。这些需求要进一步划分为核心需求和附加需求，应当先着重研究核心需求，快速生产最小可用产品，等待反馈并进一步迭代。

2. 设计阶段

设计要着眼当前阶段的核心需求。不符合需求的奇怪设计，就是用户的非预期行为，就是bug。

3. 实现阶段

实现要着眼当前阶段的核心需求，尽快产出可用产品。不仅能尽快发现问题，还能快速提振团队信心，助力项目平稳发展。

4. 测试阶段

测试非常重要，可以帮助发现开发过程中没有发现的问题，还可以避免回归bug。

5. 发布阶段

发布阶段要做好数据防护，开发和上线隔离，保护数据安全。

6. 维护阶段

持续收集用户意见，并整理，从中选出有价值的部分作为下一阶段开发的参考。此外，还要收集这个版本中出现过的问题，并修复bug。

三、心得

这次团队项目中我们合作得非常愉快，大家各尽所能，充分交流，利用研讨室集中开发，进行快速交流。我们还全程坚持了 git 规范，遵守 checkout -- commit -- rebase -- merge 的流程，使仓库的主分支呈现瑰丽的直线。团队成员的新奇想法也往往能得到其他队友的支持，大家合力实现。结对编程也是一次难忘的体验，使我感受到了同伴Push下的高强度开发。总得来说本学期的软件工程课充满意义与价值，我也很高兴。