个人总结

软件工程课程总结（王朝东自述）

开学初的计划表还钉在宿舍书桌前：每周500行核心代码、10个单元测试用例、两篇技术博客。如今翻看GitHub记录：核心代码达标率92%（第四周采购模块少写日志追溯功能），但测试用例完成率仅68%。最典型的对比是第三周计划用状态机实现采购订单流转，"待审核→已批准→发货中"的主流程实现了，可"部分退货"子状态因技术债搁置。测试环节的落差更明显：计划中清晰的"车牌号校验功能"，面对实际测试要求里的"需支持新能源车牌与军牌"时团队陷入混乱，最终花了三天才补全正则表达式。

当初读《构建之法》提的五个问题，现在能回答的只有三个半。关于"需求频繁变更"，经历过采购审批从三级改为五级的痛苦后，我懂了这是业务逻辑深化的必然代价；"文档时间占比过高"的困惑，在接口文档纰漏导致两天联调失败后得到了解答；而"单元测试是否值得"的疑问，在库存模块因85%测试覆盖率高效重构时烟消云散。但"三人组敏捷实践效果"仍无解，每周试图进行的站立会议总被专业课打断，这种团队规模是否真适合极限编程？

新冒出的问题像代码里的TODO标签般扎眼。当测试要求"实现高并发访问"，明明课程还没讲到线程池配置，我们只能边查文档边改，结果五百并发测试时TPS卡在210；还有需求描述里的模糊地带："用户友好界面"究竟需要快捷键支持还是向导流程？最困惑的是技术分歧难裁决，李同学坚持MyBatis-Plus做采购单管理，我想用JPA保证可移植性，老师展示的京东架构案例虽好，学生团队是否有方法建立技术选型评估矩阵？

重看第四次事后诸葛亮会议记录时背脊发凉。三月为赶进度跳过的采购单幂等校验，在四月订单合并功能上线后爆发重复提交故障。三人熬通宵补版本号锁，耗时是初期开发的四倍。同期坚持测试覆盖的库存模块，添加序列号追踪只花两天。这正印证邹欣老师说的"技术债务利息"，但学生项目周期短是否该允许策略性负债？

技能评价表显示单元测试覆盖率从35%提到68%，而无法量化的是对复杂性的敏锐度。以前看到需求变更就头大，现在学会先问："会影响状态机的哪条跃迁路径？"就像优化库存查询时，主动提议用黄金分割算法替代全表扫描，把五千条记录查询压到280ms。这种思维转变虽没数字衡量，却在期中答辩时被评委称赞"具备工程化思考"。

如果明年能重设课程，我会建议三点：一是教学节奏更合理，分布式事务刚学理论就进项目冲刺让人手忙脚乱；二是测试资料增加技术边界说明，例如"车牌号校验"应明确是否含港澳车牌；三是三人组规模在成员病假时太脆弱，当李同学发烧两天，采购与库存接口调试直接停滞。另外建议把实验课的SVN换成GitFlow，有次合并冲突导致半天进度白费。

最后三个问题仍在思考：
当测试内容超前于课程进度（如要求OAuth2认证），是应视作超纲挑战还是扩展学习机会？

模糊需求（如"鲁棒性输入校验"）频发时，能否建立学生反馈通道补充案例细节？

技术决策难裁定时，是否可引入架构评估模型（如决策矩阵）替代主观争论？

结课前夜调试库存预警模块，突然发现工程思维早已渗透。那些曾觉得琐碎的文档修订、接口幂等性调试、状态机跃迁测试，现在看都是抵御混乱的铜墙铁壁。或许正如王建民老师第一节课说的："你们今天处理的每个边界条件，都在为明天的系统崩溃买保险。"

课程问题
教学节奏与知识断层：当测试要求涉及未授知识（如线程池配置），学生团队应如何界定合理挑战范围？

模糊需求处理机制：面对歧义性测试描述（如"鲁棒性输入校验"），是否可建立标准化澄清流程？

微团队决策模型：三人组技术选型分歧时，有无科学的评估框架（如成本/扩展性/可维护性）替代主观选择？