[I.3]个人作业：结课总结
[I.3]个人作业：结课总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR |
| 这个作业的要求在哪里 | https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR/homework/15687 |
| 我在这个课程的目标是 | 学习软件工程思想与技能 |
| 这个作业在哪个具体方面帮助我实现目标 | 总结课程历程和收获 |
对预习阶段提出问题的回答
问题1：单元测试如何平衡尽早编写与避免过度设计？
现在我的理解是，不用追求100%覆盖率，把核心逻辑和关键边界情况测到就行。
这个认识主要来自团队项目里实际写测试的体验。我们的校园助手后端用了 pytest，目录 campus/backend/tests/ 下有十几组测试。回来翻看这些测试，发现重要的是"测试关键部分"。举几个例子：
test_auth.py：注册、登录、重复邮箱、错误密码——正好把认证模块最可能出 bug 的路径覆盖了test_schedule.py：日程 CRUD、时段冲突检测、按天/周筛选、批量导入覆盖旧数据——每个操作都有正常和异常两种用例test_budget_service.py：新用户满配额、刚好到限额被拒绝、超限被拒绝、Redis 异常时"放行不阻断"（fail-open）——尤其是最后这个，Redis 挂了不应该影响用户正常请求，这种边界场景如果没测，线上出问题很难排查
项目里的测试有几个特点让我理解了"怎么平衡"：
- 用了 SQLite 内存数据库和 FakeRedis（见
conftest.py），测试不依赖外部服务，跑得快、不用搭环境 - fixture 复用了测试数据准备，比如
test_user、client每个测试文件都能直接用，不用重复写 - 没为 getter/setter 或简单路由写测试，只测了有业务逻辑的地方——这其实就是"不过度设计"
问题2：结对编程在队友能力不均时怎么办？
查了资料和实践后发现，不一定要用经典的"一人写一人看"模式。能力差距大时可以用"导师带学徒"的方式，高手多讲思路，新手多动手写。关键是选对匹配方式，不是一刀切。
实践过程中我和结对成员的能力没有太大的差异，写代码的方式是谁有好的思路谁就写代码，另一个人这时候就负责提醒后面该写什么，以及负责检查代码中的错误。当两个人的想法不一样时，会快速地讨论一下两个方案有没有优劣之分。因为这次的结对作业除了最后一部分比较简单，在方案上没什么讨论余地，所以最大的感觉是两个人之间互相指正逻辑错误，能够避免很多一个人编程时会出现的错误。
新问题： 远程结对编程和坐在一起编程，差距到底多大？
问题3：如何在有限资源下选择合适的用户调研方法？
实践下来的感受是，学生项目里最快有效的是"做原型 + 找几个人访谈"。我们团队试过发问卷，回收率低且回答质量很差。后来改成拿低保真原型给同学走一遍流程，能挖出更多真实问题。Nielsen 说的"5个用户就能发现85%的可用性问题"确实有道理。
新问题： 做企业级产品和做面向用户的产品，调研思路会有什么不一样？
问题4：PM到底要做什么？
我觉得 PM 最核心的几件事是：搞清楚先做什么后做什么（优先级）、确保各方信息同步（沟通）、对各个成员任务的分配（分配）。有点像书上说的"除了开发和测试什么都做"。
在小组实践中，我小组的PM主要做过：确定项目内容、确定各个阶段工作、分配各成员分工、效果验收和反馈。我们小组成员要做的就是把PM构想中的项目功能做出来，做出来的效果要符合PM的要求。
问题5：团队如何平衡敏捷流程和实际开发？
我们的团队项目用了简化版的敏捷：所有人都一起开会在这种小项目里是没有必要的，我们小组成员采用每两天向PM汇报进度，成员之间微信交流的方式来实现沟通。这样不需要大家经常抽出时间聚在一起的时间了，交流的方式比较灵活。
新问题： 在ai编程能力逐渐增强的背景下，项目成员之间的工作交流、成员分工应该怎么进行，是不是有些工作应该交给一个ai来完成，而不是让好几个ai完成？
六个阶段的收获
需求阶段：需求获取与验证
学到的知识点是需求获取方法的选择。常见的需求获取方法包括问卷调查、用户访谈、焦点小组、可用性测试、原型调研等。不同方法在成本、效率和适用场景上差异较大，需要根据项目资源和目标选择合适的方法，而非把所有方法都用一遍。
在校园助手项目的需求阶段，团队最初设计了一份问卷来收集学生对校园工具的需求，但回收率低、回答质量参差不齐。后续调整为先用 Figma 制作低保真原型（包含日程管理、POI 查询等核心界面），再找几位同学进行演示和访谈。这种方法获取的反馈更具体：例如有同学在看过原型后提出"课表和校园地图应该能在同一个页面快速切换"，这个需求在问卷中很难被表达出来。
设计阶段：接口先行
学到的知识点是接口先于实现（API-first Design）：在编码开始前，前后端先共同约定好 API 的路径、请求体和响应体，双方以此约定为边界分别开发。
在校园助手项目中，后端用 Pydantic 定义了各操作的 schema，同一资源按操作类型拆分为不同的 schema（如日程的 Create/Update/Response），各操作的输入输出字段范围精确，避免了创建和更新共用一套字段的问题。接口约定通过 FastAPI 自动生成 OpenAPI 文档后，前端直接据此构造 mock 数据开发页面，后端同步实现业务逻辑，两端并行推进。
实现阶段：前后端数据映射
学到的知识点是前后端数据模型的适配转换。后端 API 返回的数据结构和前端页面需要的格式往往不一致，需要在实现阶段建立清晰的映射层，而不是直接在后端返回格式上写前端逻辑，或反过来在前端按后端格式存储数据。
在校园助手项目中，前端 api/schedule.ts 定义了专门的转换函数来处理这种差异。例如 mapBackendSchedule() 将后端返回的 BackendSchedule（字段名为 snake_case，如 day_of_week、start_section）转换为前端使用的 ScheduleItem（字段名为 camelCase，如 weekday、startSection）；createBackendSchedulePayload() 反向将前端数据转为后端请求格式。这样做的好处是：后端修改数据库字段名时只需改映射函数，前端页面组件不需要改动。
测试阶段：测试隔离
问题 1 已讨论了测试覆盖的平衡，这里补充测试隔离的知识点。
项目的测试配置（conftest.py）使用了 SQLite 内存数据库（sqlite:///:memory:）替代本地 PostgreSQL，并用自定义的 FakeRedis 类替代真实 Redis。每个测试用例在独立的数据库环境中运行，测试结束后清理数据。这样保证了测试之间不相互影响，避免了因前一个测试残留数据导致后一个测试间歇性失败的问题
发布阶段：环境一致性
在前端项目中，uni-app 代码编译生成微信小程序（输出至 dist/dev/mp-weixin/）；后端通过 uvicorn 启动服务。这一阶段学到的知识是环境一致性管理。
项目通过以下方式保证不同环境（开发、测试、CI）的行为一致：requirements.txt 锁定 Python 依赖版本，.env.example 提供环境变量模板而不包含真实密钥，CI 流水线通过环境变量注入测试数据库和 Redis 的连接信息。环境一致性降低了"在我电脑上能跑"的问题发生的概率。
维护阶段：技术债管理
项目后期的开发中，早期代码缺少注释和文档导致理解成本增加，这是技术债的典型表现。学到的知识点是：技术债需要纳入迭代计划定期处理。
具体实践包括：每个迭代在 test_schedule.py 中补充新的测试用例，覆盖后续发现的边界情况（如冲突检测、按天筛选、批量导入覆写已有数据）；维护 IMPLEMENTATION_SUMMARY.md 和 README.md，使项目的新加入者或一段时间后的自己能够重新理解项目结构和当前状态。技术债不被管理时会累积导致后续开发效率下降，因此应当将重构和文档更新作为迭代的固定组成部分。
课程心得
这门课程上，我第一次体验团队项目开发。虽然从效果上来看表现得非常不专业，但我体会到团队开发与个人开发的差别，以及过程中哪些环节可能遇到的困难。例如团队分工、团队协作我认为还存在很大学习空间。
浙公网安备 33010602011771号