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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	在 PSP 和 TSP 中磨炼自身
这个作业在哪个具体方面帮助我实现目标	通过深入回顾和总结，梳理了软件工程各环节，更加深刻理解PSP/TSP方法论的应用

1. 链接到以前提问题的博客

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

2. 对曾经提出的问题的解答

问题一：如何处理文件的锁定问题？
通过团队项目的实践，我们采用了分支策略+自由签出的方案。在Git中，每个功能开发都在独立分支进行，通过Pull Request合并到主分支。这种方式既避免了文件锁定导致的阻塞，又通过Code Review保证了代码质量。例如在Alpha阶段，前端和后端并行开发时，通过分支隔离解决了多人修改同一模块的冲突。

问题二：代码合并冲突的解决？
在团队项目中，我们频繁使用git rebase保持提交线清晰。当出现冲突时：

1. 通过git blame定位修改者
2. 使用 IDE 的冲突解决工具可视化处理
3. 必要时立即语音沟通确认逻辑。

问题三：快速获得干净代码环境？
在Beta阶段的紧急Bug修复中，我们实践了：

git stash
git checkout -b hotfix
# 修复代码
git commit -m "紧急修复"
git stash pop

这种方法让我们在1分钟内就能切换上下文。

问题四：标记稳定版本？
在发布Alpha版本时，我们使用：

git tag -a v1.0-alpha -m "首个可演示版本"
git push origin --tags

同时配合CI/CD流水线，自动将打标签的版本部署到测试环境。

问题五：大马哈鱼洄游模型的应用
在实际开发中，我们遇到了前端开发资源紧张的情况。此时，原本负责后端的2名同学临时转向前端开发，协助完成了ReactFlow节点联动功能的实现。这种灵活的跨职能协作，就像大马哈鱼从海水（后端）洄游到淡水（前端）的过程，有效解决了阶段性人力瓶颈。

问题六：对话框按钮设计
这个问题源于对《构建之法》中UI设计细节的思考。在实际项目中我们发现，当对话框需要用户做出关键决策时（如删除操作），使用明确的动作动词（[保存]/[放弃]）比通用的[OK]/[Cancel]更能减少误操作。虽然我们的小项目没有做A/B测试，但在代码审查时会特别关注这类交互设计。

问题七：预防者与治理者
在小团队实践中，我们更强调"全员预防"。

• 每日例会预留时间讨论潜在风险
• 编写自动化测试被视为与开发同等重要的工作
• 鼓励任何人随时打断编码过程提出架构质疑

3. 各阶段学到的知识点

需求阶段：用户故事地图
通过将知识库管理的用户旅程可视化，我们发现遗漏了"批量导入失败后的恢复流程"。例如有用户提出："当上传100份文档中途失败时，我需要知道哪些已经成功处理"。

设计阶段：设计冗余
在为LLM服务设计接口时，我们在业务逻辑和第三方API之间增加了适配层。当OpenAI突然变更响应格式时，只需修改适配器而不用重构核心业务代码，这让我们在1天内就完成了兼容性更新。

实现阶段：测试驱动开发
在开发embedding服务时，先编写测试用例再写实现代码。有个测试用例要求"处理包含emoji的文本"，促使我们提前发现并解决了编码转换问题，避免了后续的线上故障。

测试阶段：逐步发布
新对话功能先面向内部团队开放，根据反馈发现移动端显示异常。修复后才逐步推送给5%、20%的用户，最终实现平滑上线。

发布阶段：更新文档
使用飞书文档记录版本更新，用颜色区分更新类型（红-重大/蓝-新增/绿-修复），并附带升级指南和测试截图。

维护阶段：及时通知
通过飞书机器人实现分级告警：紧急问题自动打电话通知，重要问题群内高频提醒，普通问题每日汇总。

4. 项目心得

结对编程： 角色轮换带来意外收获。当我从驾驶员转为领航员时，反而发现了自己编码时忽视的3个边界条件，这让我理解到"换位思考"的技术价值。

团队项目： 沟通成本呈指数增长。团队采用"每日例会+异步文档"的方式，比频繁开会效率高出许多。

最重要的领悟： 软件工程是平衡的艺术。在用户权限系统设计时，我们发现：完整的RBAC权限模型开发周期需要2周，而简单的角色分组方案3天就能完成。通过分析后台数据，发现80%的用户只需要3种基础权限，最终采用混合方案，既满足核心需求又节省了60%的开发时间。