软件工程课程个人总结：从技术实践到工程思维的蜕变

一、课程计划执行深度回溯
​​目标达成率​​：课程初期制定的3项核心目标基本完成，关键数据如下：

​​Spring Boot进阶​​：主导团队web软件工程学习系统的后端开发，完成核心API接口的开发，基于springboot+MybatisPlus完成项目后端的搭建。
​​安卓开发入门​​：接入自研后端API实现工单管理模块，完成了个人学习系统应用，实现基本Android应用开发。
​​技术博客输出​​：将个人开发的系统源代码上传到博客园，不过没有具体的源码解析内容。
六级证书：未完成。
​​最深刻的教训​​：在团队项目的数据库设计中，因过度追求范式化（3NF）导致工单-设备-维保记录三张表关联过于复杂，多次出现跨表查询超时。这与初期计划中“简化数据结构”的设想背道而驰，印证了《构建之法》中的观点：“​​过度设计比不设计更危险​​”。

二、构建之法问题自答与认知升级

初期疑问	当前理解	认知迭代点
“为什么需求总是变更？”	需求本质是动态平衡	用户场景驱动变更​​：用户上传图片时，因环境光线问题导致失败
“代码注释越多越好吗？”	在团队协作中发现：冗余注释掩盖关键逻辑，如工单状态转换仅30%注释有价值	应聚焦于“为什么这样做”（如@StateMachine注解解决并发冲突）而非“做什么”
“敏捷开发是否适合学生团队？”	Beta阶段采用双周迭代，但需求拆解粒度不均导致部分模块延期	敏捷的本地化实践​​：需建立“燃尽图+每日站会”的轻量级监督机制

​​悬而未解的问题​​：
​​如何量化评估架构设计质量？​​ 课程中通过评审定性判断，但缺乏类似代码覆盖率的客观指标。这恰是软件工程课难以回答的——​​架构的合理性需经生产环境检验​​。

三、新问题：从项目阵痛中诞生的思考
​​1.跨平台一致性如何工业化实现？​​
团队因Web（Vue3+Element UI）与Android（Jetpack Compose）的组件库差异，导致相同数据表单布局偏差率达30%。业内是否已有成熟的​​设计系统开发规范（如Figma Token自动化导出）​​ 降低适配成本？
2.​​遗留系统的数据库改造如何避险？​​
在修复ER图缺陷时，为新增工单操作日志表，牵一发而动全身。
​​3.如何构建现场工程师的精准用户画像？​​
测试代码时，图片上传会因现场环境变化而产生新的问题。
四、文献与实践碰撞后的新感悟
回顾团队“事后诸葛亮”会议记录，产生三点突破性认知：
​​“焦油坑”的现实映射​​：在数据库存储图片方式问题上，因过度纠结导致其他模块开发延迟。这印证了Brooks法则——​​纠结细节的投入产出比随时间指数级下降​​，应建立技术方案止损机制。
​​设计模式的双刃剑​​：在工单状态管理引入状态模式（State Pattern），虽提升扩展性但增加代码量，为后续用户操作带来了不便。证明​​模式应用需以用户心智模型为核心​​，而非技术优越性。
五、技能跃迁：数字与感知的双重成长

技能维度	量化进步	非数字收获
技术能力	Spring Boot响应速度优化	​​架构权衡意识​​：为保工期放弃OCR识别方案，转为人工审核兜底
工程管理	Git协作提交量提升3倍，分支冲突率下降60%	​​​​风险嗅探能力​​：在数据库设计阶段预判外键缺失风险，推动建立Flyway脚本库
产品思维	测试BUG数降低	​​同理心设计​​：构建用户应用场景，优化用户体验

​​最珍贵的蜕变​​：彻底摆脱“编码即正义”的学生思维，修改许多实际使用下来会造成不便与误操作的设计，从用户角度思考问题。

六、一年后的回望：课程优化建议
1.引入“​​灾难日演习​​”：模拟生产环境事故（如数据库崩溃），训练团队应急响应
2.建立​​领域知识卡点库​​：汇总高频技术难题（如Spring事务传播机制）并提供企业级解决方案，同时推动​​跨团队代码交换评审​​：打破组间技术壁垒，预防“闭门造车式开发”
3.前置课《数据库原理》需加强​​反范式设计案例教学​​（如电商库存管理的数据冗余实践）
​​结语​​
这门课像一面棱镜，折射出我作为开发者的多面性：曾因一个算法优化沾沾自喜，却在测试时因为一句“为什么要点这么多次？”中无地自容。这让我顿悟：​​工程师的终极使命，不是征服技术高峰，而是弥合数字世界与血肉之躯的鸿沟​​。一年后当我迈入职场，定会记得那个图片审核机制的错误判断——它时刻提醒我：所有代码终将流向人间。