个人总结

1. 回顾课程计划完成情况
   在第一周的计划中，我制定了以下目标：

学习《构建之法》并整理核心概念（完成度：90%）：阅读了前8章，整理了需求分析、版本控制、敏捷开发等核心内容，但未深入阅读测试与维护部分。

完成团队项目的需求分析文档（完成度：100%）：团队使用NABCD模型撰写了需求文档，并通过评审。

掌握Git基本操作（完成度：100%）：通过实践，熟练使用git branch、git merge和PR流程，团队仓库提交记录达50+次。

参与两次代码评审（完成度：50%）：仅完成一次，因时间安排冲突未完成第二次。

撰写每周学习总结（完成度：80%）：共提交12篇周报，但第9周因考试未提交。

具体数据：

代码贡献量：约2000行（主要涉及前端界面和API调用）。

文档产出：需求分析1份、设计文档2份、会议记录6份。

团队会议：共8次，全员参与率75%（2人因实习缺席3次）。

实际例子：
在项目初期，我们误将“施工计划”和“施工申请”合并为一个表，导致后续权限管理混乱。通过“事后诸葛亮”会议，我们拆分数据库表并优化了审批流程。

2. 对《构建之法》五个问题的回顾与回答
   在课程初期，我提出了以下问题：

问题1：如何平衡敏捷开发与文档撰写？
回答：实践中发现，敏捷并非不写文档，而是精简文档。我们使用Markdown记录关键决策，并用GitHub Wiki维护动态文档。

问题2：如何有效进行代码评审？
回答：通过团队实践，我们规定：

单次PR不超过300行代码；

必须至少两人评审；

使用TODO标签标记待改进点。

问题3：需求变更频繁时如何管理？
回答：课程未完全解决此问题。我们尝试用MoSCoW法则（Must-have, Should-have, Could-have, Won’t-have）优先级排序，但仍受限于客户沟通效率。

问题4：如何衡量个人贡献？
回答：使用GitHub Insights统计代码量，但发现非代码贡献（如文档、测试）难以量化。最终采用“自评+互评”机制。

问题5：如何避免“过度设计”？
回答：通过MVP（最小可行产品）思路，先实现核心功能（如施工计划提交），再迭代扩展（如照片水印）。

未解决的问题：问题3（需求变更）因缺乏真实客户场景，课程未提供系统方法。

3. 新产生的问题
   如何在小团队中实施自动化测试？

我们仅对核心模块写了单元测试（覆盖率约30%），但时间不足导致部分功能依赖手动测试。

多人协作时，如何统一代码风格？

虽配置了ESLint，但仍有成员忽略规范，需更严格的工具集成（如Git Hooks）。

如何评估技术债的优先级？

课程未涉及技术债管理策略，团队仅凭经验处理。

希望老师和助教解答的问题：

是否有轻量级的自动化测试框架推荐？

如何说服团队成员遵守代码规范？

技术债该在何时偿还？有无量化标准？

4. 对“事后诸葛亮”分析的新感想
   通过复盘会议和阅读文献（如《人月神话》），新的认知包括：

沟通成本被低估：初期认为每日站会足够，但实际上需额外文档同步细节（如接口字段定义）。

技术选型影响后期维护：使用低代码平台快速搭建界面，但导致定制化功能开发困难。

风险管理不足：未预留缓冲时间应对第三方API延迟（如短信验证码服务）。

改进方向：

引入Swagger规范API文档；

在计划中增加20%的缓冲时间。

5. 技能提升与无形收获
   可衡量的提升（对比初期自评表）：
   技能项 初期水平（1-5） 当前水平（1-5）
   Git协作 2 4
   需求分析 3 4
   单元测试 1 3
   无形收获：
   团队协作：学会在分歧时用数据（如用户调研结果）说服队友。

项目管理：意识到“完美主义”可能导致延期，需权衡质量与进度。

6. 对课程的未来建议
   假设一年后进入职场/读研，我认为课程可优化：

教学方法：增加“真实客户模拟”环节（如邀请企业导师扮演需求方）。

助教工作：提供更多代码评审示范（如录制讲解视频）。

课程衔接：与“数据库系统”课程联动，避免重复讲SQL基础。