539 字
3 分钟
从手抄代码到初涉工程化
核心复盘与顿悟
- 写代码最难的不是语法，而是“定义需求”：
以前遇到“继续游戏”这种功能，经常陷入上来就写
router.push的局限。事实上必须先反问“什么是继续游戏”、“中断点存在哪”等边界条件，在实现复杂需求前把业务状态流转梳理清晰，后续代码落地才能顺水推舟。 - 工程化开发不是堆砌功能，而是“制定规则”： “继续游戏”看似简单，实质是对游戏状态机甚至持久化体系的完整建模。路由守卫不再是单纯的拦截器，而是维护整个系统一致性的规则关卡。
知识内化与经验沉淀
🛠️ 工程化思维
- 拒绝重复造轮子：
以前开新项目靠复制粘贴，今天把模板传到 GitHub，配合
new-ccb脚本，一行命令拉取环境。GitHub 是仓库，脚本是物流车，自动化才是程序员该干的事。
🏗️ 架构与逻辑设计
- 显式优于隐式（以 Continue 功能为例）：
纠结过用路由守卫自动记录路径，但最终选择在关键页面手动更新
continuePath。虽然多写一行代码，但逻辑绝对可控，避免了误触等垃圾信息。 - Pinia 的角色划分与持久化：
- 持久化：不用自己操心
localStorage，Pinia 配合插件既有响应式又能自动存本地。 - 边界清晰：队伍、关卡、游戏全局状态拆分成不同的 Store，各司其职，避免大杂烩。
- 持久化：不用自己操心
- Router 即流程： 未选角不能进地图、未通关不能进下一关。这些规则写在守卫里，Router 就成了维护游戏流程完整性的核心骨架。
总结
将需求前置，通过清晰的状态管理和确定的规则执行，能够最大程度提升代码的可控性。从“手工作坊”般复制粘贴代码，切入到具备可组装、自动化流程的工程思维，这正是长期系统建设中的重要基石。
部分信息可能已经过时