本次门店运营管理系统从立项到答辩，是一次把“工程化思维”落进真实业务的实践。最初我们以为只是常规的后台管理，但逐步发现：门店、员工、职位、身份、检查项与检查类型、工作日历等模块之间的约束与边界，才是复杂度的来源。我们在不断地拆分问题、梳理契约、统一规范中，把“能跑”提升为“可维护、可协作、可交付”。

开发过程中最深的体会有三点。其一，需求要“可度量”。早期口头同步导致前后端对字段语义、校验规则、分页协议理解不一，联调时成本陡增。后来我们用接口清单与 Mock 明确输入输出，让协作从“猜”变为“证据驱动”。其二，分支策略与提交粒度决定团队效率。采用功能分支、小步提交、清晰描述后，Code Review 与回滚都更可控。其三，先设计“失败态”再做“成功态”。验证码过期、登录失败、图片上传异常、网络抖动等一旦兜底完善，用户体验会显著提升。

在技术选型上，后端以 Spring Boot + MyBatis 为主，结合 Redis 做验证码与热点数据的缓存，JWT 承担无状态鉴权，配合拦截器统一处理登录态；统一返回体与全局异常让前端能稳定消费；定时任务承载一些公共作业。前端使用 Vue + Element，通过路由守卫与 axios 拦截器管理权限与请求生命周期，组件化沉淀了表单校验、列表分页、图片上传、工作日历等能力。真实落地后，我更能体会“分层清晰、边界明确、约定统一”对迭代速度的支撑。

团队协作上，我们先后踩过几类坑：接口变更未宣达导致前端报错、同文件多人改动引发冲突、测试环境配置与本地不一致。对应的改进包括：建立变更公告与版本号、推进模块负责人制、在 README 中固化环境变量与启动步骤、用接口用例对齐数据契约。到后期，联调节奏与质量明显提升。

个人成长方面，我从“写功能”转向“做设计”。学会先画出模块交互与数据流，再编码；对查询性能、索引设计、缓存策略有更直观的判断；能把复杂表单与交互（如工作日历的批量设定）拆成数据结构与状态流问题；在表达上，能把技术权衡转译为业务价值与风险，便于团队达成共识。

项目的亮点在于：技术栈稳定、分层合理、通用能力可复用、关键模块覆盖完整；不足在于：自动化测试覆盖不高、缺少压测与监控、权限模型仍偏基础、前端在大数据量场景还可进一步性能优化。若继续演进，我会优先补齐单测与接口测试，完善监控告警，细化 RBAC/ABAC 权限，并在前端引入表格虚拟化与异步分片渲染。

回看这段旅程，我更确定：工程的核心是“对齐与确定”。当目标被说清、契约被写清、流程被跑顺，编码就会变得顺畅。愿未来我们继续以用户价值为锚，以工程质量为底，把每一次迭代都做成可复用、可沉淀的成果。