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

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	掌握软件工程的的相关理论，在实践中掌握相关方法，培养团队协作解决问题的能力
这个作业在哪个具体方面帮助我实现目标	对本学期学习的内容进行回顾总结

一、之前提问的博客

旧博客链接

二、对旧问题的解答

问题1：冲刺中途被要求紧急改动，应该拒绝还是接受？

我现在的理解是：接受。
在Alpha阶段最后，进行小程序注册的时候因为社交属性需要企业级注册，不得已在最后一两天对前端进行了紧急修改。如果在做项目时遇到紧急改动，必然是某一环节出现了严重问题，这是不得已而为之，如果拒绝会让事情变得更麻烦。在这一学期的学习中，我体会到一个道理：先把事情做完，再把事情做好。我认为这对于新手开发项目很适用，缺乏经验必然会遇到很多难以预判的问题，而过度追求完美往往会陷入“分析瘫痪”的陷阱。但与此同时，软件工程课程教会我的是：“做完”只是及格线，“做好”才决定一个工程师的上限。 真正的专业素养，是在完成交付的基础上，不断优化流程、沉淀方法，让团队从“每次都在截止日前熬夜”走向“从容地高质量交付”。

问题2：如何在团队协作中平衡“完成任务”与“共同成长”？

我的能力在团队中是比较差的，好在后端的工作有很多是分成两部分完成的，我可以借鉴队友完成的思路完成另一部分，在这学期我在队友身上学习到了很多，在向队友学习的同时，利用学到的东西完成任务，在实践中练习了学到的东西，平衡了成长与完成任务。

问题3：结对编程中，如果双方水平都不高，该怎么办？

这学期的结对作业发布后我立即阅读了作业内容，了解了相关知识，之后在结对编程时发现队友的水平和自己差不多，都不高，但是合作起来很愉快，两个人讨论写题思路的时候进程很快，编程的时候一个人编程，一个人监督，避开了很多不必要的小错误。即使两个人水平都不高，但只要专心解决问题，合理沟通，水平低也能很快解决问题。

问题4：代码覆盖率100%是否真的值得追求？

我现在的理解是：不值得作为绝对目标去死磕。 从80%拼到100%的精力可能远超前80%，而这些精力往往耗费在极少触发的边缘分支上。测试的核心目标是测出bug、保障核心逻辑的可靠性，而非追求一个好看的百分比。在实际项目中，我更倾向于将测试精力集中于核心模块和易错区域，把覆盖率作为持续关注的趋势指标，而非强制执行的门槛。一个覆盖率100%却没人想用的产品，远不如一个覆盖率70%却解决了用户真实痛点的产品有价值。

问题5：如何在团队中选出合适的PM？

本学期我们团队成员之间都不了解，所以抽签选了一个人当PM。可以看出来，抽签选出来的PM做事也很生疏，就拿编写团队博客作业举例，开始的时候PM不知道怎么安排，之后有人提议把任务分成几部分，队员各自认领一部分，PM做最后总结整理，之后的博客作业都是这样完成的。整个项目有前后端两部分，PM参与前端工作，对后端只是大概熟悉，这就需要一位后端的同学来配合，逐渐形成了前端PM和后端PM的双PM工作组合。总之，如果一个团队中有非常熟悉整个项目规划的人来当PM当然好，不过如果没有这样的人，那“干中学”和随机应变就很重要了。

三、产生的新问题

经过一个学期的学习和实践，我遇到的新问题是：在这个AI时代，后端的很多工作可以丢给AI来完成，开发者只需要做好项目规划，敲定项目细节和方向，有完整的规划书，AI就可以快速编辑出初版demo，那我们要做的和要学习的是什么？

四、各阶段学到的知识点

需求阶段：用户故事必须可量化验证

• 在项目初期，我们的需求文档中写了很多类似“界面要友好”“响应速度要快”这样模糊的描述。直到开始做小程序原型时，我们才发现“友好”在每个人心中的标准完全不同——有人觉得按钮越大越友好，有人觉得信息密度高才高效。这让我深刻理解了软件工程中“SMART原则”的价值：需求必须具体、可度量。后来我们把需求重新表述为“首页加载时间不超过2秒”“核心操作路径不超过3步”“按钮点击热区不小于44×44pt”，需求才真正从“共识”变成了“可验证的标准”。

设计阶段：模块划分的核心是接口契约而非内部实现

• 在做系统设计时，我们自然地把项目分成了前端、后端、数据库三层，但真正让我学到东西的不是“怎么分”，而是“怎么定义接口”。我们三个人每人负责一部分接口，每个人的接口返回的数据有多有少，虽然程序跑起来了，但是看起来很乱，最后只能整体整理一遍，浪费了很多时间。

实现阶段：持续集成和本地测试

• 每次写完后要在本地做好测试工作，及时合并，每次合并前先拉取主分支、解决冲突、跑通本地测试再推送。

测试阶段：多个模块组合后会有新BUG

• 单元测试保证“零件合格”，联调保证“接口严丝合缝”，场景测试保证“用户旅程畅通”，回归测试保证“修好不弄坏其他”——四者结合，才是完整测试策略。

发布阶段：发布流程要熟悉

• 微信小程序在发布阶段遇到了很多问题，微信审核需要排队，第一次被驳回因为隐私政策未明确说明；社交功能需要企业级的注册；修改后重新提交又等了一天；审核通过后还要手动点击“发布上线”才算真正对用户可见。

维护阶段：Bug修复的第一原则是“不引入新问题”

• 修复线上bug的第一原则不是“快”，而是“稳”——动手改代码之前，先写回归测试把现有功能锁住，确保修复操作不会破坏任何已经正常工作的部分，因为修一个已知问题却引入三个未知问题，是所有维护场景中最不可接受的失败。

五、个人项目/结对编程/团队项目的心得体会

个人项目：个人作业让我意识到软件不能只看能不能跑通，还要了解用户体验、竞争力等方面，要抓住用户的核心痛点，让我了解到软件工程为什么叫“工程”，因为它不仅是编写代码就可以，还需要很多代码之外的考量，是需要多方配合多方协作的过程。
结对编程：结对开发的过程中，我第一次体会到了两个人合作编程的乐趣和效率，两个人针对一个问题快速讨论，交流思路，明显比一个人单独思考要快很多，在听对方的思路的时候很可能会启发自己产生新的更好的思路，结对编程真的让我感到很愉快。
团队项目：“时光航迹”是我第一次真的参与完成的完整项目实践。在多人协作中，我第一次认真看别人编写的代码，通过分析别人的代码来学习，提升自己。另外，我意识到沟通的重要性，团队之间良好的沟通能大大加快问题的解决速度，每一次开完组会都会让我更清楚下一步要做什么、还有哪没有做好。