个人作业-提问回顾与个人总结

项目	内容
这个作业属于哪个课程	2023 年北航敏捷软件工程
这个作业的要求在哪里	提问回顾与个人总结
我在这个课程的目标是	学习软件工程相关知识，提高自己的代码能力与团队协作能力
这个作业在哪个具体方面帮助我实现目标	对本学习所学内容进行总结

一、对个人作业-阅读和提问中提问的回答

• 工作量和质量评估：如何选取指标从何综合性地对一项软件的开发过程进行评估呢？

  答：综合评估软件开发过程可以采用以下方法：

  1. 评估模型：使用成熟的评估模型，如CMMI（Capability Maturity Model Integration）或ISO 15504（SPICE），来评估软件开发过程的能力和成熟度。这些模型提供了评估框架和指南，可以综合考虑多个方面的指标。
  2. 权衡考虑因素：将工作量和质量指标进行综合权衡，根据项目的特定需求和限制，确定合适的评估方法和指标权重。例如，如果项目有时间紧迫的要求，可能需要更关注工作量指标；如果软件的可靠性是最重要的目标，可以将质量指标的权重提高。
  3. 经验数据分析：利用过去项目的经验数据进行分析，比较不同项目的工作量和质量指标，找出相关性和规律。这有助于制定合理的评估指标和基准。
  4. 定期评估和改进：评估软件开发过程应该是一个持续的过程，定期进行评估并根据评估结果进行改进。通过反馈和学习，不断优化和提升软件开发过程。

• goto语句的使用：为了实现单一出口而使用goto语句是否合适？

  答：使用goto语句可能带来的影响如下：

  1. 可读性和可维护性：goto语句导致代码的跳转，使得代码的流程和逻辑难以理解。它会增加代码的复杂性，使得代码难以维护和调试。阅读和理解带有goto语句的代码需要跟踪跳转目标，而且很难推断代码的执行路径。
  2. 逻辑混乱和错误风险：goto语句使得代码的控制流程变得不明确，可能导致逻辑错误的引入和隐藏。使用goto语句的代码可能变得混乱和难以控制，增加了出错的风险。通过使用结构化的控制流语句（如if语句、循环语句等），可以更清晰地表达代码逻辑，降低错误的可能性。
  3. 跨模块和模块间的耦合：goto语句可能导致代码的非局部性跳转，使得代码的模块化和封装性受到影响。使用goto语句跳转到其他模块或函数可能导致代码之间的紧密耦合，降低代码的可维护性和可扩展性。良好的模块化设计和良好的函数接口设计应该避免跨模块的goto语句。
  4. 可移植性和规范性：某些编程语言和编译器对于goto语句的支持不一致，因此使用goto语句可能降低代码的可移植性。此外，许多编程规范和最佳实践建议避免使用goto语句，以保持代码的一致性和可读性。

  综上所述，尽管goto语句在某些情况下可能有其用途，但在大多数情况下，遵循结构化编程原则，并使用清晰、可读性强的控制流语句，可以提高代码的可读性、可维护性和可靠性。

• 结对编程：结对编程真的高效嘛？或者说，什么情况下适合结对编程？

  答：我认为结对编程并不适用于所有情况。以下是一些需要考虑的情况：

  1. 复杂性和独立性：结对编程在处理复杂的任务和涉及多个模块的代码时可能更加适用。对于较为简单和独立的任务，结对编程可能过于冗余和低效。
  2. 团队成员技能差异：如果团队成员之间的技能差异较大，结对编程可能会导致不平衡的合作，其中一个人可能成为主导者，而另一个人则更多地处于被动学习的角色。
  3. 工作环境和个人偏好：结对编程需要团队成员之间进行紧密的合作和交流，这对于一些人来说可能不适应或不舒服。同时，结对编程需要提供适合两个人使用的工作环境，如共享屏幕、键盘和鼠标等。

• 典型用户：典型用户是否存在主观偏差？如何更合理地设计典型用户？

  答：一般来说，如果我们在创建典型用户时没有做足够的用户研究，或者让我们自己的主观偏见影响了对用户的理解，那么我们定义的典型用户就有可能带有主观偏见。这样的典型用户可能会导致产品设计偏离真实用户的需求和行为。

  要避免这种情况，我们需要在设计典型用户时采取一些策略，以下是一些建议：

  1. 数据驱动：尽可能基于真实的用户数据创建典型用户。这可以是通过用户调查、用户访谈、用户观察或数据分析得到的数据。
  2. 多元化：在可能的情况下，创建多个典型用户以反映用户群体的多样性。
  3. 持续更新：典型用户并不是一次性创建就完毕的，它们需要随着我们对用户理解的深化和产品的发展进行持续的更新。
  4. 团队参与：让产品团队多人参与典型用户的创建过程，可以避免单一人的主观偏见。
  5. 关注行为而非人口统计信息：虽然人口统计信息（如年龄、性别、职业）有时可以帮助我们更好地理解用户，但更重要的是理解用户的行为和需求。

  这些方法有助于我们更准确、更客观地创建典型用户，从而使我们的产品设计更接近真实的用户需求。

• 有错不改：对于修改成本巨大的bug有错不改真的利大于弊嘛？

  答：有些情况下，一个 bug 的修复成本确实可能超过其潜在造成的影响，使得保持现状成为更可取的选择。以下是一些例子：

  1. 大规模影响：如果一个 bug 影响到了大量已经在使用的系统，例如Excel 日期问题，修复它可能需要修改大量的数据或代码。这个过程中可能出现新的错误，甚至可能导致系统的不稳定。同时，因为需要更新的系统数量巨大，修复成本也会非常高。
  2. 向后兼容性问题：如果 bug 的修复会破坏向后兼容性，这可能会对依赖于旧版本行为的系统产生影响。例如，某些系统可能已经采用了一些方法来适应这个 bug，如果 bug 被修复，这些系统可能需要进行更新，这也会带来额外的成本。
  3. 用户适应性：如果用户已经习惯了 bug 的存在，并已经找到了一些方法来规避这个问题，那么修复 bug 可能会导致用户需要重新学习如何使用系统，从而带来不必要的麻烦。

  然而，这并不是说我们应该总是选择不修复 bug。在许多情况下，尤其是对于可能导致安全问题、数据丢失或者严重影响用户体验的 bug，修复它们通常是非常重要的。即使修复成本高，也是值得的，因为这样可以保护用户的数据安全，提高用户的满意度，以及维护品牌的声誉。

二、在项目的 需求/设计/实现/测试/发布/维护阶段中学到的内容

需求分析
通过学习NABCD需求分析方法，我们的用户需求分析过程变得更加系统化和有条理。在我们的团队需求分析过程中，我们先头脑风暴了一些典型用户的初步需求，然后我们结合用户视角和实现难度，筛选并细化了一些合适的需求，进一步将它们转化为具体的实施需求。

设计阶段
我们编制了详细的功能规格说明书和技术规格说明书，遵循相关规范和原则进行记录，以便于后续开发工作的顺利进行。同时，我们遵循信息隐藏原则和接口设计原则，以确保后端接口的安全性和可靠性。

实现阶段
在实现阶段，我们遵循一定的代码规范，通过使用Coding平台来分配任务。每个组员都需要在Coding平台上详细地编写出他们的设计方法和基本的实现策略，以便于后续的开发和测试。同时，我们制定了一套完整的“发现缺陷-报告缺陷-修复缺陷-确认修复”的流程，以便于后续的测试工作。

测试阶段
我们使用了Coding平台的issue模板，并设立了一套完整的“发现缺陷-报告缺陷-修复缺陷-确认修复”的流程，这大大提升了我们的测试效率。此外，我们还指定了一位同学来进行正确性测试和压力测试，以最大限度地避免产品在发布时出现重大bug。

发布阶段
在产品发布时，为了吸引更多的用户，我们进行了一系列的推广活动。通过在微信朋友圈、QQ、B站等平台上宣传我们的产品，我们成功扩大了产品的影响力，并吸引了不同背景的用户使用我们的产品。

维护阶段
尽管我们已经进行了严格的测试，但产品在发布后仍然不可避免地会出现一些bug。因此，我们设立了用户微信群，用户可以在发现bug后及时反馈给我们，我们也可以及时对这些问题进行修复和更新，尽最大可能降低用户体验的不适。

三、结合在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得

一学期的软件工程中，虽然十分辛苦，但是学到了很多知识与技能，最终做出了一个相对完整的作品，还是收获颇丰。在整个过程中，我发现自己对于工程开发的流程还是比较陌生，对于团队开发的工具，比如git的各种操作都不够熟悉，导致给团队里带来了一些麻烦。但是在熟悉整个开发流程后，开发就变得比较顺利，大大提升了整个项目的完成效率。最后，很感谢软件工程这门课程，感谢助教和老师的付出，也感谢靠谱的队友们~