有个梨UGlee
2019-12-04 14:07:42 发布
tdd的最大价值在于：

如果你发现测试写不下去，应该立刻停止写代码，开始写文档。

文档检查三类问题

1 接口是不是太隆重，太多行为语义，难以长命百岁
2 内部结构是不是太复杂，不够literal，太难以维护状态一致性
3 关系是不是太混乱，难构造，难销毁，数据流不简单清晰

把需要的使用方式一条一条列出来，包括功能如何提取和更新数据，包括各种constraint如何enforce，在哪里enforce，包括数据流路径上的每个组件是不是责任简单，只做source，sink，fan in，fan out或者filter一种角色。

通常的设计困难都发生在：
1 一些操作早期没考虑清楚，感觉上实现没问题，结果真正实现的时候发现爬reference爬的混乱
2 一些数据流上的节点承担了太多角色，既负责维护数据，又做了复杂的分发策略，尤其是要根据业务要求出现调用外部模块更新其状态

解决的方式就是
1 考虑数据路径增加模块封装责任
2 考虑使用事件和观察者模式规避对外部模块的调用，这是最重要的去耦合方式

把所有的业务要求都在脑子里dryrun一遍，确认接口，结构，关系三件事情都理顺了，再开始写代码或测试。tdd不是必须的工程路径，但是把问题问全了想透了是应该先做的。