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

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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	学习软件工程的思想和方法，进行软件开发的实践
这个作业在哪个具体方面帮助我实现目标	总结软件工程课程的收获

原问题

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

问题1 如何理解软件工程中的Bug

在实际的使用过程中，用户可能在非预期的情况下使用软件，导致行为与期望不符。用户的个人经验和背景也会影响他们的期望。不同用户群体可能对同一功能有不同的预期。例如，习惯使用某个软件的用户可能会期望其他类似软件有相同的操作方式。如果新软件的行为不同，用户可能会认为这是bug，但实际上这只是设计选择的不同。
对于这些用户对于bug的看法，开发人员应该如何平衡用户的主观意见？

在开发过程中，当收到用户反馈的疑似 Bug 问题时，我们首先从技术层面判断是否属于真正的软件缺陷，区分是设计选择差异还是程序错误。同时，结合用户群体调研和数据分析，确定该 “Bug” 影响的用户范围与频率，若只是少数用户基于个人习惯的误解，将通过引导文档解释；若涉及大量用户的使用体验问题，则纳入开发计划优化。

问题 2 单元测试是否应该追求覆盖率

在开发的过程中，单元测试会占用许多的时间成本，很多开发团队要求单元测试高覆盖率。但在实际开发中，某些代码（如getter/setter）可能不值得测试，覆盖它们反而浪费成本。同时，单纯追求高覆盖率可能导致无意义的覆盖，即开发者编写大量低效的测试用例，只为了覆盖代码行，而不验证实际功能。例如，调用了某个方法但没有断言其结果，这样的测试虽然提高了覆盖率，却毫无意义。
在以上的情景下，单元测试的高覆盖率是否有意义？是否有更好的指标衡量测试结果？

在项目开发中，我们摒弃单纯追求高覆盖率的做法，对于核心业务逻辑和容易出错的代码模块，制定较高的覆盖率目标并编写详细的测试用例；对于像 getter/setter 这类简单代码，仅进行少量抽查测试。
同时，我们在测试中使用了 “缺陷发现率” 和 “测试用例有效性” 等指标，用来评估测试结果，确保测试工作聚焦于发现真正的问题，而非盲目追求覆盖率。

问题 3 结对编程能否真正提高开发效率

在结对编程的过程中，两人的技术水平可能存在差异，此时有可能出现强势者主导开发的现象，另一方参与度低，产生心理负担；同时，在产生意见分歧的时候，由于双方知识结构、开发习惯的差异，可能无法说服对方，从而导致开发停滞。

在结对编程时，我们两人定期交换主导和辅助角色，避免一方长期主导，从而减少一方参与度低的情况。当我们对如何实现某个功能或者解决某个问题产生意见分歧时，会进行沟通和协调。
实际开发中，结对编程能否提高开发效率取决于开发者的合作程度、技术水平差异以及沟通能力。如果这些因素得到妥善处理，结对编程确实能带来更高的效率。

问题 4 开发团队中PM的职责是什么

PM的工作范围可能覆盖开发和测试之外的大部分事务，比如任务分配、进度跟踪、风险管理等工作，有时甚至要包括客户沟通、需求收集等工作。这样做可以减少开发者的非技术性负担，让他们专注于编码。然而，如果PM缺乏技术背景，可能会在某些决策上不够准确，从而影响整个项目的推进。此外，如果PM同时负责市场、其他部门沟通等任务，是否会使PM的职责过于繁杂，降低团队的效率？

在开发过程里，我们明确划分了 PM 的核心职责边界，并根据 PM 的能力特点进行任务分配。对于技术背景较弱的 PM，我们安排了开发人员协助其进行技术相关决策，确保需求和任务分配的合理性。

问题 5 敏捷开发中文档的必要性

在敏捷开发的过程中，主张以沟通为主，减少需求分析、详细设计等文档的编写。然而，文档不足可能导致后期维护困难，新加入开发团队的成员难以充分了解整个项目；同时，软件交付后，用户也可能对文档有一定依赖。一个敏捷开发的团队如何平衡敏捷开发准则和对文档的需求？

在开发过程中，我们采用 “轻量级文档 + 持续更新” 的方式平衡需求。对于核心需求和架构设计，编写简要清晰的文档，并在每次迭代后根据实际开发情况更新。同时，利用github记录开发过程中的关键信息，方便团队成员随时查阅。

在项目的 需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么“知识点”

需求阶段：需求获取与分析方法

通过与用户进行访谈、问卷调查、观察等方式获取需求，同时运用用例图、需求规格说明书等工具对需求进行详细分析和记录。

设计阶段：前后端分离架构设计

采用前后端分离架构设计应用程序，前端专注于用户界面展示和交互逻辑，后端负责业务逻辑处理和数据管理。这种架构模式实现了前后端开发人员的并行开发，提高开发效率；同时降低了系统耦合度，便于后期功能扩展和维护，也能根据前后端不同的性能需求进行针对性优化。

实现阶段：版本控制工具 Git 的使用

在代码实现阶段，Git 作为版本控制工具发挥了关键作用。它可以记录代码的每一次修改，方便团队成员追溯历史版本、查看修改记录。通过分支管理功能，开发人员能在不影响主分支的情况下进行新功能开发和问题修复，待功能稳定后再合并到主分支，保障了代码的稳定性和可维护性，也便于团队成员之间的协作开发。

测试阶段：自动化测试框架的应用

在测试阶段，引入自动化测试框架，针对我们开发的应用程序的功能、性能等方面编写自动化测试脚本。自动化测试能够快速、重复地执行测试用例，在每次代码提交后自动运行，及时发现因代码修改引入的问题，相比手动测试大大提高了测试效率和准确性，也能覆盖一些手动测试难以触及的边界情况和复杂场景。

发布阶段：持续集成与持续部署（CI/CD）

在发布阶段，运用持续集成与持续部署技术，将代码提交、构建、测试、部署等流程自动化。当开发人员提交代码到仓库后，CI/CD 系统自动触发构建和测试流程，若测试通过则自动将应用部署到生产环境。这一过程减少了人工干预，降低了出错概率，实现了快速、稳定的版本发布，让应用能够及时交付给用户。

维护阶段：日志监控与错误追踪

在应用维护阶段，通过设置日志监控系统，记录应用运行过程中的关键信息和错误日志。当出现问题时，开发人员能够根据日志快速定位错误发生的位置和原因，分析问题的影响范围。结合错误追踪工具，还能对问题进行跟踪和统计，为后续优化和改进提供数据支持，保障应用的稳定运行 。

心得体会

经过本学期软件工程课程的学习与实践，我在软件工程中的各阶段任务中，都有了很大的收获。在个人作业中，从阅读《构建之法》到进行软件分析，我初步认识到软件开发的基本流程；在结对编程中，我通过和搭档合作开发，体会到协作与沟通的重要性；在团队开发中，我意识到，团队项目中清晰的分工、有效的沟通和科学的项目管理缺一不可，只有各环节紧密配合，才能确保项目顺利完成，也深刻理解了软件工程中各阶段知识协同运用的重要性。