学期总结

软件工程课程总结：从代码搬运工到工程思维者的蜕变
姓名：XXX 团队：鹰 项目：智慧图书管理系统
时间：2025年6月10日

1. 课程计划完成度：数据驱动的目标达成
   初始计划目标（第一周制定）：

掌握敏捷开发全流程（Scrum+Kanban） → 完成度95%
实践证据：团队完整执行3次Sprint迭代，燃尽图覆盖率100%（附迭代2燃尽图）
https://example.com/burndown-chart

代码质量提升（单元测试覆盖率>60%） → 完成度78%
实际数据：后端Java模块覆盖率72%（Jacoco报告），但前端React仅41%

撰写技术文档5篇 → 完成度40%
差距分析：仅完成《API接口规范》《部署手册》，因需求变更频繁导致文档滞后

团队协作规范化 → 完成度90%
案例：Git分支策略从混乱的“直接push到main”改进为GitFlow，冲突率下降70%

关键教训：文档与技术债需列入Sprint待办项，而非“有空再补”。

2. 《构建之法》五大问题回顾：从困惑到实践认知
   原始问题 当前答案 未解原因

3. 如何平衡“足够的设计”和“过度设计”？ 通过MVP验证：仅对核心借还模块做领域建模，扩展模块用轻量设计 → 节省30%工时 已解决

4. 程序员如何有效参与需求分析？ 实践：成员轮岗担任“用户代理”，现场观察图书馆员操作 → 发现3个关键痛点 已解决

5. 测试驱动开发(TDD)是否适合学生项目？ 验证结果：核心服务采用TDD，BUG减少50%；但UI层效率低 → 需按模块差异化 部分解决

6. 如何量化“工程师能力”？ 仍无标准答案 → 团队用“代码复审通过率”“文档复用率”等8项指标评估 课程局限：评估体系依赖主观标准

7. 敏捷是否会导致技术债失控？ 亲历教训：为赶进度跳过压力测试，上线后数据库崩溃 → 必须预留20%债务偿还工时 已解决
   反思：软件工程课提供方法论实验室，但真实复杂性（如能力量化）需行业沉淀。

8. 新问题：工程实践的前沿挑战
   AI生成代码的伦理边界
   场景：用Copilot生成30%基础代码，但发现其引入GPL协议代码片段 → 是否需人工逐行审查？
   提问对象：助教（技术合规方向）

远程协作的效率瓶颈
困境：团队40%时间消耗在异步沟通（如PR评论往返），如何平衡效率与质量？
提问对象：老师（团队协作研究方向）

技术选型的长期成本
案例：为快速开发选用低代码平台，2年后扩展成本陡增 → 如何建立选型评估模型？
提问对象：企业导师（架构师）

4. 文献与复盘的认知升级
   原观点（课程初读《人月神话》）：

“添加人力总能追赶进度” → 视为过时理论

新感悟（经历项目延期后）：

人月神话的现代印证：为赶工新增2名成员，沟通成本飙升 → 进度反拖延1周（符合Brooks定律）

事后诸葛亮会的价值：

首次复盘会：聚焦“谁的责任” → 引发争吵

改进后：用“5 Why分析法”定位流程缺陷 → 产出3项有效改进（如自动化部署）

关键转变：从追究个体转向优化系统，这是工程思维的核心跃迁。

5. 技能提升：数字与心智的双重成长
   可量化能力提升（对比课程初自评）：

技能项 课前(1-5) 当前(1-5) 证据
代码重构能力 2 4 债务模块重构后BUG下降60%
需求分析能力 3 4.5 用户访谈报告被客户采纳
自动化测试 1 3 搭建CI/CD流水线
不可量化的收获：

预判风险的习惯：在迭代计划会主动追问：“这个需求有性能陷阱吗？”

技术决策的权衡思维：
案例：拒绝“实时数据大屏”需求 → 因评估计算资源超预算200%

工程责任感：从“功能能用就行”到“必须写可维护的代码”