[I.3] 个人作业：结课总结
[I.3] 个人作业：结课总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2025 年春季软件工程（罗杰、任健） |
| 这个作业的要求在哪里 | [I.3] 个人作业：结课总结 |
| 我在这个课程的目标是 | 学习并掌握软件工程的基本原理和实践方法，提高软件开发和管理的能力。 |
| 这个作业在哪个具体方面帮助我实现目标 | 通过总结本学期的学习和项目实践，反思软件工程课程的收获与成长。 |
以前提问题的博客： [I.1]个人作业：阅读和提问
一、团队项目中的个人贡献
1.1 我的职责与工作内容
在本学期的团队项目中，我在JieNote（一站式文献学习平台）担任前端开发工程师，负责关键功能模块的开发与优化。
- Alpha阶段：实现了Markdown笔记功能核心编辑器，完成文献阅读与笔记整合功能，重构了框架的token刷新结构，修复了6个关键bug。
- Beta阶段：完成了Markdown编辑器的功能升级（增加LaTeX公式支持、代码高亮等功能），实现回收站功能，开发了悬浮预览功能，提升用户体验。
1.2 关键技术难点与解决方案
Markdown编辑器与PDF阅读器的整合难点
挑战：编辑器需要与PDF阅读器同步运行，实现用户在阅读文献的同时能够记录笔记，同时保持两者之间的数据关联。
解决方案：
- 采用分屏布局设计，左侧PDF阅读器，右侧Markdown编辑器
- 实现状态管理机制，在用户切换PDF页面时保存当前编辑状态
- 设计文献与笔记的关联存储结构，通过唯一标识符将笔记与文献建立一对一映射
- 针对编辑器，选择了支持实时渲染的 Markdown 编辑器组件，并扩展了对LaTeX公式和代码块的支持
回收站功能的实现挑战
挑战：需要在不影响现有业务逻辑的情况下，添加文件删除的中间状态，支持用户恢复误删内容。
解决方案：
- 设计软删除机制，为文献和笔记对象添加
isDeleted状态字段 - 重构删除操作API，替换为标记删除
- 实现专门的回收站视图，展示已删除项目并提供恢复和彻底删除功能
- 添加定期清理机制，对超过30天的已删除内容进行自动清理
Token刷新机制的优化
挑战：原有架构中token过期处理不当，导致用户会话频繁中断，需要重新登录。
解决方案：
- 实现基于拦截器的自动刷新机制，在接收401响应时自动触发token刷新
- 设计token缓存机制，避免并发请求多次触发刷新
- 添加请求队列，在刷新token期间暂存请求，刷新成功后自动重试
- 优化登录态判断逻辑，提高系统鲁棒性
1.3 个人贡献评估
在团队项目中，我的贡献主要体现在三个方面：
- 功能实现：完成了Markdown编辑器、回收站和悬浮预览等核心功能，这些功能直接影响用户的日常使用体验
- Bug修复：解决了多个关键bug，包括编辑器内容保存丢失、PDF加载卡顿等影响用户体验的问题
- 架构优化：对token刷新机制的重构，显著提高了系统的稳定性和用户体验
通过这些工作，我不仅提升了系统的功能完整性，也增强了产品的用户体验和稳定性，获得了团队的认可和96分的团队贡献分。
二、对初始提问的解答与思考
2.1 软件需求"数学化"的实际应用范围
初始问题：软件需求"数学化"是否实际可行及其适用范围？是否仅适合低风险核心功能而不足覆盖复杂业务逻辑？
经过一学期的实践，我认识到需求数学化确实存在应用范围的限制。在结对项目中，我们实现贪吃蛇算法时成功应用了数学模型：
- 使用坐标系和向量表示蛇的移动，通过曼哈顿距离计算最佳路径
- 应用BFS/DFS算法解决路径规划问题，明确了输入状态到输出行为的映射关系
然而，在团队项目中发现数学建模的局限性：
- 用户界面和交互体验等主观需求难以数学化
- 复杂业务流程（如组织协作、权限管理）需要结合领域知识而非纯数学模型
结论：数学化方法适合于：
- 算法核心逻辑（如我们的排序、路径规划）
- 明确的输入输出映射关系（如公式计算、数据转换）
- 可量化的性能指标（如响应时间、吞吐量）
但对于涉及用户体验、业务流程等需求，需要结合其他方法，如用户故事、原型设计等进行补充。这一认识帮助我在项目中更好地选择需求描述方法。
2.2 需求蔓延问题的有效管理策略
初始问题：类似"画扇面"故事的思维误区如何通过需求管理策略有效避免？
解答：在团队和结对项目中，我们采用了敏捷开发的用户故事拆分、需求优先级排序和MVP原型验证等策略，有效防止了需求蔓延。通过定期组会和需求评审，及时调整需求边界，确保开发聚焦于核心价值。实践证明，需求管理工具（如GitHub Issue、飞书任务）和团队沟通机制对于防止需求失控非常关键。
2.3 用户故事与系统需求完整性的平衡
初始问题：用户故事碎片化与系统需求完整性矛盾如何调和？
解答：在实际开发中，我们通过用户故事驱动增量开发，同时结合需求文档和系统用例图，确保全局视角和系统边界的完整性。对于复杂功能，先用用户故事拆分细节，再用PRD文档补充全局约束，保证了需求既细致又不失整体性。
2.4 MVP原型的评估与迭代策略
初始问题：MVP原型如何量化评估核心功能与最小成本？
解答：在结对和团队项目中，我们通过用户反馈、功能使用频率和Bug数量等数据，量化评估MVP的效果。优先实现高频刚需功能，采用快速迭代和小步快跑策略，及时根据用户反馈调整开发重点。对于高成本但必要的功能，则通过团队讨论和技术预研，权衡投入产出比。
2.5 测试策略与动态交互缺陷的覆盖
初始问题：场景驱动型测试能否覆盖动态交互中的涌现性缺陷？
解答：我们在项目中采用了单元测试、集成测试和探索式测试相结合的策略。通过自动化测试覆盖常规场景，人工探索测试补充边界和异常情况。虽然无法穷举所有动态交互，但多层次测试显著提升了系统的健壮性和可靠性。
三、软件工程各阶段的关键收获
3.1 需求阶段
学会了用用户故事和用例图明确需求边界，避免需求蔓延。
3.2 设计阶段
通过组件化设计和接口契约，提升了系统的可维护性和扩展性。
3.3 实现阶段
实践了结对编程和代码评审，提升了代码质量和团队协作效率。
3.4 测试阶段
掌握了自动化测试和用例设计，提升了缺陷发现率和回归测试效率。
3.5 发布阶段
体验了CI/CD自动化部署流程，增强了对软件交付和安全的责任感。
3.6 维护阶段
通过用户反馈驱动持续优化，理解了软件生命周期的持续演进。
四、个人能力的提升与反思
4.1 前端技术栈的掌握
从AssemblyScript到vue，拓展了前端开发的技术广度和深度。
4.2 编辑器与文献管理系统的实现
攻克了编辑器与PDF阅读器整合、复杂状态管理等技术难点。
4.3 团队协作能力的进步
结对编程和多人团队协作提升了沟通、分工和协作能力。
五、软件工程课程的收获与启示
5.1 理论与实践的结合
将课程知识应用于实际项目，理论与实践相互促进。
5.2 结对项目与团队项目的差异
结对项目注重算法与协作，团队项目更考验系统设计与分工。
5.3 新的问题与思考
实践中发现需求变更、测试覆盖等问题仍需持续探索和改进。
六、结对项目与个人案例分析补充
6.1 结对项目：影蛇舞
在结对项目中，我与搭档合作开发了基于 AssemblyScript 的贪吃蛇智能体。该项目让我深入理解了需求分析、算法设计、测试驱动开发等软件工程核心环节。
- 需求分析：通过 PSP 表格细致拆解任务，明确每一步的目标和预期。
- 算法实现：针对不同任务，采用贪心、BFS/DFS 等算法，结合实际测试不断优化。
- 测试设计：利用课程组提供的 checker 工具，设计了多种边界和异常测试用例，保证了代码的健壮性。
- 结对协作：在驾驶员/领航员模式下，轮流编码与审查，提升了代码质量，也锻炼了沟通能力。
通过结对项目，我体会到良好沟通、任务分解和单元测试对项目成功的重要性。
6.2 个人软件案例分析
我选择了 Cherry Studio 作为分析对象，系统评测了其功能、用户体验、质量与市场定位。
- 功能分析：Cherry Studio 支持多模型切换、知识库管理、300+ 预设助手等，功能丰富，适合中高级用户。
- 用户体验：界面简洁但初用有门槛，细节设计有待提升。
- 质量评估：代码量大，开发周期长，稳定性和插件生态有提升空间。
- 市场分析：定位于多模型协作平台，竞争力强，但需关注移动端和插件化发展。
通过案例分析，我学会了从用户、开发、市场等多维度评价软件产品，也理解了实际开发中质量与用户需求的平衡。
七、总结与展望
本学期通过个人、结对和团队项目，系统体验了软件工程的完整流程。我的最大收获是：
- 理论与实践结合，提升了需求分析、系统设计、协作开发和测试的能力；
- 认识到沟通、分工和持续集成对团队项目成功的决定性作用；
- 学会了用多种视角分析和改进软件产品。
未来希望继续提升架构设计和全栈开发能力，参与更大规模的项目实践。
浙公网安备 33010602011771号