课程总结

一、课程计划完成度回顾
初始计划：完成运维管理子系统，实现APP端和web端的运行
实际完成：

1. 需求分析：清楚了解典型用户的需求，符合预期
2. 技术栈：Spring Boot+Vue+MySQL+
3. 团队分工：开发岗完成度120%（额外实现自动化测试脚本），文档岗滞后（仅完成80%接口文档）
   关键数据：燃尽图显示冲刺末期日均代码量达350行/人（超计划40%）

---

二、《构建之法》问题回顾与自答

原问题	自我解答	未解原因
1. 如何平衡敏捷开发与文档规范？	采用轻量级文档（如用户故事卡）+自动化文档生成工具	需长期项目验证
2. 个人技术能力不足如何影响团队？	通过每日站会暴露瓶颈，采用结对编程补救	已解决
3. 用户需求频繁变更如何处理？	设立需求冻结期+变更影响评估矩阵	实践中评估精度不足
4. 测试应何时介入开发流程？	采用Shift-Left测试（需求阶段编写测试用例）	已在CI/CD中实践
5. 如何量化软件工程质量？	引入SonarQube指标（代码重复率<5%，覆盖率>70%）	技术债量化仍困难
反思：问题2/4通过课程实践解决，问题1/3/5需更多工程经验——这正是课堂无法模拟的真实项目复杂性。

---

三、新产生的三个问题

1. 技术债管理：学生团队如何在不影响交付的前提下系统化偿还技术债？（如重构排期）
2. 远程协作效能：当80%沟通转为线上（如钉钉/腾讯会议），如何避免信息碎片化导致的决策延迟？
3. 伦理困境：若用户需求涉及隐私过度采集（如运维系统需收集员工操作录像），开发者责任边界在哪里？

（希望老师和助教指导）

---

四、文献复盘与“事后诸葛亮”新感悟

重读文献：《人月神话》中“没有银弹”的启示
项目复盘发现：

• 原认知：认为延期是因技术难点（如运维告警聚合算法）
• 新洞察：沟通成本才是瓶颈（前端/后端因接口歧义平均每天浪费1.5小时）
  行动改进：

1. 采用OpenAPI 3.0规范强制定义接口
2. 设立跨组“术语词典”（如统一“告警静默”的定义）
   核心收获：软件工程本质是降低熵增的过程，而文档是最佳减熵工具。

---

五、技能提升对比

量化提升（对比学期初）：

技能项	初值	终值	增幅
Git协作熟练度	3/10	8/10	+167%
单元测试覆盖率	45%	78%	+73%
代码评审效率	2PR/h	5PR/h	+150%

非量化收获：

• 风险预判能力：在运维子系统开发中提前识别权限设计缺陷，避免迭代后期重构
• 妥协艺术：为保障交付，接受技术方案折衷（如用Shell脚本替代Python自动化部署）
• 领导力认知：协调冲突时发现“倾听比说服更重要”（如平息技术栈争论）

---

六、对课程的未来建议

假设场景：一年后进入互联网公司任后端工程师
反思建议：

1. 教学方法：

   • 👍 优势：MVP开发模式培养“交付思维”
   • 改进：增加灰度发布模拟环节（如A/B测试运维策略）

2. 助教工作：

   • 建议建立标准化反馈模板（例：代码评审需含“严重/建议”两级注释）

3. 课程衔接：

   • 前置课程需强化分布式基础（本课程中Redis集群配置成最大痛点）
   • 后续建议开设DevOps专项实践（延续运维子系统经验）