核心用法
coding-philosophy 是一套关于软件开发方法论的思维框架，源于作者通过10轮直觉驱动迭代开发游戏的实践经验。它提出"感觉优先"与"结构优先"两种工作模式的辩证关系，并提供具体的重构检查清单。
两种模式的切换机制：
感觉优先模式（创意模式）：用于探索"要构建什么"。强调速度、表达和发现，允许重复、死代码和线性搜索，命名基于当下功能而非抽象分类。适用场景：原型开发、游戏创作、首次版本构建。
结构优先模式（工程模式）：用于优化"已构建的东西"。提取重复模式、缓存热路径、清理死代码、按关注点组织。适用场景：生产代码、团队协作、性能关键循环。
五项关键观察：
1. 感觉优先代码会积累"幽灵"（死变量）——这是创意考古学，而非技术债务
2. 模式在命名前就已浮现——3处以上重复即暗示函数提取机会
3. 表现性优先于性能——find()在60fps循环中虽慢但清晰
4. 数据/逻辑边界最初模糊——重构时分离二者是低风险高回报操作
5. 直觉产生的结构通常正确——重构应清洁而非重新设计
三大哲学根基：
- 可错论：死代码是考古学，非羞耻；错误是发现正确架构的路径
- 关系本体论：代码是与未来自我、协作者、用户的跨时空对话
- 荒诞游戏：感觉优先即游戏——跟随有趣线索，添加无人要求的彩蛋
显著优点
- 实践验证：源于1800行游戏代码的真实迭代经验，非纯理论推演
- 操作性强：提供6步重构检查清单（审计→缓存→提取→组织→清理→优化）
- 认知友好：承认开发者认知状态差异，反对单一"正确"工作方式
- 创意保护：为原型阶段的"混乱"正名，减少开发者的羞耻感
- 历史意识：强调git提交保留考古价值，反对激进删除
局限与风险
- 主观性强："感觉"难以量化，新手可能难以判断模式切换时机
- 语境依赖：经验主要来自游戏开发（视觉、交互、创意），对数据处理、企业系统等领域的迁移性未验证
- 规模上限不明：未讨论大型团队（10+人）或百万行代码库的应用边界
- 性能盲区："热路径优化"建议较基础（Map索引、缓存DOM），复杂场景（内存管理、并发）覆盖不足
- 工具链中性：未绑定具体语言/框架，既是优点也是实施模糊性来源
适合人群
- 独立游戏开发者、创意技术工作者
- 原型驱动的产品开发者
- 从"能跑就行"向"可维护"转型的个人开发者
- 对软件工艺哲学有兴趣的工程师
- 受困于"过早抽象"或"永远混乱"两极的开发者
常规风险
- 模式切换失败：在创意阶段过度优化，或在维护阶段保留过多技术债务
- git考古依赖：若团队缺乏规范提交习惯，"保留历史"建议可能沦为永不清理的借口
- 认知过载："感觉优先"可能被误解为"无思考编码"，忽视隐性的设计决策质量
- 协作摩擦：个人直觉产生的结构可能与他人认知模型冲突，需额外文档化投入
补充说明
文档末尾包含具体技术教训（IIFE作用域、sed多行替换、浏览器缓存、存档迁移等），但这些属于附带知识，非核心方法论组成部分。