在某个项目上使用TDD方式开发，结果比较惨淡。自己来说，有些"设计决策犹豫综合征"，也就是说，在写代码的时候，不知道如何处理某个问题，而卡在了那里。这样的问题希望能通过TDD改善，也就是所谓的，用最简单的方式实现就好了，不要考虑扩展性什么的，无论何时出现了问题，包括测试不通过，继续写下去的时候感觉不对，重构就好了。也就是说，不是要求一定要现在就做出决策，而是等到问题比较明显，那时候思路比较清晰的时候，再来决策，也就是说，关键的思想是，JUST MOVE ON。不要有思想的包袱，感谢重构。
而TDD最难的就是掌握节奏，就是两顶帽子轮流的时间。这一点可以说是TDD是否良好有序的进行的表征，最多连续的写一个小时的代码，就要进行反思，并可能的重构，当然并不是说重构就要在一个小时之后进行，如果你感觉有需要，就可以进行，这只是一个预警，防止你前进的太多，而忘了自己在做什么。离开桌子，站起来想想。
这一周感觉项目的进度逼着，希望尽快做一些东西出来，结果错误的想先写好一个类的所有的测试用例，并且在每一个测试用例里面先写好各个probe，这样子当然是不行的。我们应该建设的是a web of object，而不是单单一个类。应该从最基本的需求开始，完成它， 通过测试，然后添加probe或者其他的用例。这个项目是在做PC和手机端的通信，一开始是想要做好异步和同步两种方式，虽然这是可以预期的设计，但是也许会误以为同步才是最基本的方式，想要先完成发送一个请求，然后阻塞的等待回复这个用例开始。但是在这个情景里，反而异步才是最基本的方式，反而应该从异步模式开始。