*-Driven 方法论不能替代经验
Backlinks (0)
No backlinks found
1 · *-Driven 方法论不能替代经验#
1.1 · 核心观点
TDD、BDD、DDD 这类 *-Driven 方法论，本质上都是经验丰富的人对过去实践做出的抽象总结。
它们可以帮助人建立语言和观察角度，但不能替代经验本身。
真正决定效果的，不是你背了多少口号，而是你是否有能力在具体上下文里判断：这个原则什么时候适用、适用到什么程度、什么时候该偏离它。
进一步说，*-Driven 框架只是入口，最终还是要回到它们背后的软件设计底层原则：职责、封装、组合、依赖、约束、演化。
1.2 · SCQA#
S 场景：软件行业涌现大量 *-Driven 心智框架（TDD、BDD、DDD……），每个都承诺让开发更好、更快、更便宜，并配有朗朗上口的 meme（Red-Green-Refactor、Given/When/Then、Building Blocks）。
C 冲突：这些框架的作者（Kent Beck、Dan North、Eric Evans）都是在多年跨项目经验基础上，通过归纳推理提炼出框架的。但使用者往往缺乏同等经验，面对新上下文时无法正确解读框架，结果要么教条式硬套、要么放弃回到旧习惯——五种可能反应中三种会导致挫败。
Q 问题：为什么经验丰富的人不太需要框架（他们已有自己的心智模型），而真正需要框架的人又用不好？
A 回答：
- 框架是经验的凝结，不是经验的替身：作者先从实践里归纳，再把结论演绎到更多场景；这一步天然有边界。
- 框架必须被解释，而不是被执行：同一套口号落到不同团队、业务和技术约束里，需要不同解释；解释能力本身就是经验。
- 基本功比口号更重要：与其执着于某个
*-Driven标签，不如先练好职责划分、封装边界、组合方式、依赖治理、约束表达和演化能力。这也和 软件设计的哲学 里“优先降低复杂度”的方向一致，并可落回软件设计底层原则。 - 成长路径不靠背诵方法论：更有效的方式是做项目、跨上下文迁移、接受反馈，以及在师徒制或评审里学习别人如何判断。
1.3 · 框架与底层原则
如果把 *-Driven 方法论看成工具层，那么真正更稳定、也更可迁移的，是工具背后的原则层。
- TDD 表面上强调
Red-Green-Refactor，底层更是在用测试约束设计，倒逼职责清晰、接口可替换，并让代码更容易演化。 - BDD 表面上强调
Given/When/Then，底层更是在统一行为表达，明确系统边界与规则，减少团队协作中的理解偏差。 - DDD 表面上强调实体、值对象、聚合、限界上下文，底层更是在处理边界划分、职责分配、依赖方向与模型演化。
换句话说，框架的价值不只在于“教你一套动作”，而在于提醒你去观察：这个方法究竟在解决哪一种结构性问题。
可以粗略对应到软件设计底层原则中的六项原则：
TDD：更偏向约束、职责、演化。BDD：更偏向约束、封装、组合。DDD：更偏向职责、依赖、组合、演化。
这种映射不是严格分类，而是帮助自己在使用框架时不断追问：我现在学到的，到底是一套流程，还是一种可迁移的设计判断？
1.4 · 启发
- 方法论最大的价值，往往不是“告诉我怎么做”，而是“给我一个更好的讨论语言”。
- 一个团队如果只复制 测试驱动开发 或 行为驱动开发 的表面动作，却没有理解它们想解决什么问题，最后只会多出一层流程负担；如果能继续追到背后的职责、封装、依赖、约束和演化问题，框架才真正开始发挥作用。
- 当你开始把框架当作裁判，而不是当作辅助观察的透镜时，设计判断通常已经退化了。
- 软件开发真正应该被驱动的，首先是利益相关者的需求，其次是工程常识，以及那些跨语言、跨框架都成立的底层原则，而不是某个流行缩写。
1.5 · 一句话总结
*-Driven 方法论是经验的结晶，不是经验的替代品；框架可以帮你看见问题，但不能替你做判断。
真正要学会的，不是框架本身，而是框架背后那组可迁移的底层原则。
没有经验的人会把框架当答案，有经验的人会把框架当工具。