我终于顿悟了,TDD 其实只是一种管理代码的方法论,犹如 GTD 之于时间管理,犹如 PKM 之于知识管理,而非决定代码质量的具体设计指导。
Github 里所有关于 TDD 的代码最后都会迁移到这个仓库来。既然 TDD 只是一个方法论,那么它的问题域就是帮你在明确了需求的前提下,更快速、高效地写出好的代码。其核心是快速反馈、无用代码一行都不多写,通过减少无效代码(非需求代码)及长反馈周期带来的时间浪费,以此提升撸码过程的效率。
因此,TDD 不能帮你明确需求(如果你不知道如何明确需求),也不能帮你写出好的代码(如果你本来就不知道如何写好代码、不知道设计);TDD 能做的,是在你的需求基本明确的情况下,通过 tasking 的辅助方式,让你更专注地完成有效任务;而关于代码质量和设计,TDD 无法也本来就不是这方面的工具。
TDD 中产出的测试确实能作为重构的基础保障,但这只是附加价值,并非采用 TDD 的核心动机。代码质量,需要通过整洁代码、设计模式等来长期维护。
git clone git@github.com:linesh-simplicity/bravo-tdd-test-driven-development.git./gradlew clean build --refresh-dependencies./gradlew check./gradlew clean junitPlatformTest$ claude mcp add more-effective-TDD \
-- python -m otcore.mcp_server <graph>