[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 |
| 我在这个课程的目标是 | 学习现代软件工程的基本思想，理解敏捷开发、结对编程、软件项目管理等方法，并能够在实践中应用这些方法完成软件项目。 |
| 这个作业在哪几个具体方面帮助我实现目标 | 通过回答课程学习前的问题，总结软工大作业和结对作业的收获，进一步加深对敏捷开发，结对编程，软件项目管理的理解，总结实践经验 |
一. 五个问题的回答
问题博客链接：https://www.cnblogs.com/404-error-64/p/19701182
问题1：结对编程在什么情况下能够真正提高开发效率？
通过阅读结对编程相关内容和完成“花见小路”结对项目，我认为结对编程更适合复杂度高、规则陌生、需要快速统一理解的任务。
“花见小路”项目要求两个人在有限时间内理解新规则、完成编码任务并记录过程。如果一个人独立做，很容易在需求理解或边界情况上走偏；而结对时，一个人负责实现，另一个人负责检查思路和规则是否符合题意，可以减少返工。
但如果任务只是简单修改、重复编码或很明确的小功能，结对编程可能会增加沟通成本。因此我认为，结对编程真正提高效率的场景是：任务复杂、时间紧、风险高、需要共同理解需求或需要知识共享时。
问题2：Scrum 或 Sprint 中如何进行任务时间估算？
通过阅读敏捷开发和 Sprint 的内容，并结合项目实践，我认为任务估算不能只靠直觉，而要先拆分任务，再根据历史经验估算。
一个大的任务应该拆成多个小任务。例如在 Scider 项目中，“完成端到端测试”并不只是写测试代码，还包括调试验证码、处理 Redis 限流、确认 Docker 环境、整理测试报告等。如果一开始只估算写代码时间，就会低估工作量。
因此，比较合理的方法是使用 Story Point 估算任务复杂度，再结合团队过去的 Velocity 判断一个 Sprint 能完成多少任务。同时还要留出一定缓冲时间，应对需求变化和技术问题。这样计划才更可行。
问题3：NABCD 方法中如何确保需求真实有价值？
通过阅读 NABCD 方法和结合 Scider 项目实践，我认为验证需求不能只靠开发者自己的想法，而要回到真实用户场景。
例如 Scider 项目中的论文上传、笔记管理、知识图谱和 AI 问答功能，背后的需求是帮助用户更高效地阅读和整理论文。这个需求是否真实，不能只看功能是否做出来，而要看用户是否真的能通过完整流程解决问题。
因此，在写项目建议书时，需要通过用户访谈、问卷调查、竞品分析和最小可用产品验证需求。只有当目标用户确实存在痛点，并且愿意使用这个解决方案时，NABCD 中的 Need 和 Benefit 才是可靠的。
问题4：“软件的血型”在实际工程中有什么作用？
通过阅读“软件的血型”相关内容，我理解它的作用是帮助团队判断不同软件应该采用不同的工程策略。
例如长期运行的后端服务、数据库和任务队列，需要更重视稳定性、测试、监控和可维护性；而一次性脚本或临时工具，则更重视快速实现和解决当前问题。
在 Scider 项目中，后端接口、Docker 部署和端到端测试都属于需要长期维护的部分，因此要写文档、做回归测试和监控；而一些临时修复脚本则不需要同样复杂的设计。由此我理解到，软件分类可以影响架构设计、测试强度、文档要求和维护方式。
问题5：如何进行有效的项目事后复盘？
通过阅读 post-mortem 和 retrospective 的内容，并结合 Scider 项目实践，我认为有效复盘不能只停留在“总结问题”，而要形成具体改进措施。
一次复盘应该先回顾目标和结果，再记录过程中遇到的问题，然后分析根本原因，最后提出可执行的改进。例如 Scider 项目测试过程中遇到验证码、环境变量、Redis 限流和 Docker 重启等问题，如果只是说“环境配置麻烦”，帮助不大；更有效的做法是把解决方案写成文档或脚本，方便以后复用。
因此，有效复盘应该是基于事实、无责备、追溯根因，并且产出明确的改进行动。只有这些行动在后续项目中被验证，复盘才真正起到改进流程的作用。
二. 在需求/设计/实现/测试/发布/维护六个阶段中学到了什么知识点？
1. 需求阶段：需求要能落到可验证的用户场景
我学到的知识点是：需求不能只写成“实现某个功能”，而要描述用户在什么场景下使用它，以及如何判断它完成了。
在团队项目中，我参与的功能包括 PDF 解析、四要素提取、知识图谱生成和 AI 问答。如果只说“实现论文解析功能”，这个需求是不够清楚的。后来我理解到，真正的需求应该是：用户上传一篇论文后，系统能够自动解析文本，提取背景、方法、创新点和结论，并让后续的图谱和问答功能使用这些结果。这样需求就和用户场景、后续功能、测试标准联系起来了。
2. 设计阶段：复杂功能要拆成异步任务和清晰的数据流
我学到的知识点是：对于耗时长、依赖外部服务的功能，不能都放在一个同步接口里完成，而要设计成异步任务。
例如 PDF 解析、向量化、调用 Embedding API、LLM 图谱生成等功能都比较耗时。如果用户上传论文后，后端接口一直等待所有任务完成，响应会很慢，也容易超时。因此项目中使用 Celery 和 Redis，把 PDF 解析、向量化等任务拆成后台任务，再通过任务状态接口轮询结果。这个设计让我理解到，软件设计不只是写接口，还要考虑响应速度、任务状态、失败重试和用户体验。
3. 实现阶段：接口实现要关注数据格式和模块协作
我学到的知识点是：实际编码时，最容易出问题的不是单个函数，而是模块之间传递的数据格式。
我参与的任务中有“与前端联调图谱渲染数据格式”和“实现图谱数据接口”。图谱需要返回节点和边，前端渲染依赖字段名、结构和类型。如果后端字段格式和前端预期不一致，即使算法本身正确，前端也无法展示。因此实现阶段不能只关注后端逻辑，还要和前端约定好 JSON 格式，例如节点 id、label、category，边 source、target、weight 等。这个过程让我认识到，接口契约是前后端协作的关键。
4. 测试阶段：端到端测试能发现单元测试发现不了的问题
我学到的知识点是：端到端测试不是简单地测接口是否返回 200，而是验证完整业务流程是否真的能走通。
我主要参与了端到端全流程回归测试，覆盖注册、登录、PDF 上传、解析、四要素确认、笔记、图谱、AI 问答、密码重置和多用户隔离。测试过程中发现，很多问题不是单个接口的问题，而是流程连接处的问题，例如验证码写入 Redis、rate limit 影响自动化测试、Docker 环境变量未生效等。最终 36 个端到端用例全部通过，让我更深刻理解到：只有把完整用户路径跑通，才能证明系统真正可用。
5. 发布阶段：Docker 部署要关注环境变量和服务依赖
我学到的知识点是：发布不是把代码放到服务器上就结束了，还要保证数据库、Redis、后端、Worker 等服务之间能正确连接。
在部署相关工作中，我接触了 Docker Compose 配置。服务器上不一定有完整代码，可能只有镜像、.env 和 docker-compose.yml，代码已经被打包到镜像中。后端依赖 MySQL、Redis，Worker 也依赖同样的数据库和消息队列，因此环境变量如 DATABASE_URL、REDIS_BROKER_URL 必须正确配置。这个过程让我理解到，发布阶段最重要的是服务编排、环境隔离和依赖健康检查。
6. 维护阶段：监控和压测是发现系统瓶颈的重要手段
我学到的知识点是：系统上线后，不能只看功能是否可用，还要关注它在高并发下是否稳定。
我参与了高并发压测准备，使用 Locust 模拟 100+ 并发用户上传 PDF、生成图谱和发起问答请求，同时在服务器端监控 CPU、内存、MySQL 连接数和 Docker 容器资源占用。这个过程让我认识到，维护阶段需要关注响应时间、95 分位延迟、错误率、数据库连接池和资源占用。功能正确只是第一步，系统能否长期稳定运行，还需要通过监控和压测来验证。
三. 结合个人项目/结对编程/团队项目经历，谈谈理解或心得
通过个人项目、结对编程和团队项目，我最大的体会是：软件工程不是单纯写代码，而是围绕需求、协作、质量和维护形成的一整套流程。
在个人项目中，很多时候我更关注“功能能不能跑起来”。因为项目规模小，一个人既写前端又写后端，很多约定都存在自己脑子里，不一定需要详细文档。但缺点也很明显：一旦功能变多，代码容易混乱，测试也不充分。
在结对编程项目“花见小路”中，我体会到沟通和共同理解需求的重要性。结对编程不是简单地两个人分工写代码，而是通过 Driver 和 Navigator 的配合，一边实现一边检查思路。对于规则复杂、时间有限的任务，结对可以减少理解偏差和返工。
在团队项目 Scider 中，我的感受更明显。项目涉及前端、后端、数据库、Redis、Celery、LLM、Docker 和测试部署，任何一个模块单独正确都不够，必须能集成起来。我参与的任务包括 PDF 解析与四要素提取测试、LLM 图谱生成、向量化 Celery 任务、图谱接口、端到端回归测试和高并发压测准备。这些经历让我认识到，团队项目最重要的是接口约定、异步任务设计、自动化测试、部署环境和监控维护。
因此，我对软件工程的理解从“写出能运行的代码”变成了“构建一个可协作、可测试、可部署、可维护的系统”。代码只是其中一部分，更重要的是让系统在真实场景下稳定工作，并让团队成员能够持续协作和迭代。
浙公网安备 33010602011771号