最近这段时间，我尝试用TDD的方式来解了几道算法题。其间颇有一些感触，希望通过这个死磕系列的文章做个小结。
为什么
有个广为流传的说法：TDD不适合解决算法问题。
对此我一直是存疑的，机缘凑巧就亲身验证了一下，动机不外乎以下几条：
- 作为TDD粉丝，难免会“不服气”，总想证明自己喜欢的方法有更广的应用范围，更大的效力。
- 另有一种常见的说法，“我不会所有代码都写测试，因为大部分代码都太简单不值得测。只有核心的逻辑复杂的代码才需要单元测试或TDD”。按照这种标准，涉及算法的代码自然是复杂的。如果两条都认同，基本上等于说TDD没有什么适用的地方了。
- 现实工作中的问题不会在自己头上贴张“我是算法问题”的标签。即便真的TDD不适合算法，至少也应该尝试找出一些经验法则去察觉目前的问题需要改变方法。
特别是如果严格执行TDD三法则的话，让我们回顾一下三法则：
a. 在编写失败的测试前，不能编写实现代码；
b. 只编写恰好能失败的测试；
c. 只编写恰好能通过测试的实现代码；
可以看到整个步骤是按部就班，环环相扣，严格覆盖所有代码的。假定开发者真的接受这套方法，并且前面也进展顺利。总不能等到一步步深陷泥潭了才有人过来说：“bingo，这是个算法问题，不适合用TDD”。
这相当于司机跟着语言导航驾驶，结果不知不觉掉入坑里。然后却去责怪他，“这段路的导航工作不正常，你怎么不停下来问问人啊？”完全是不负责任的说法。 - 虽然有相当数量的Kata可以作为TDD的练习题目。有时候我还是稍有怀疑这些Kata是不是因为恰巧适合TDD而被选中的。所以也想用具有一定挑战的算法题目来验证用这种方式对解决问题的帮助有多大。
导航
怎么开始的
因为一直有这个念头，在今年初偶然看到@东东 同学组织的“每日一题”群时就加了进去。
每日一道算法题
软广一下
每日一题是个专注于刷题练习算法的社群。每天早晨群主大人都会准时喂一道算法题给嗷嗷待哺的码农，每周有主题，定期有回顾，时不时还有直播讲解。
有志于学习算法，或者准备刷题找工作的同学。都可以搜索微信公众号“每日一道算法题”加入。
群里小伙伴都很厉害，往往一道题贴出来半个小时就有答案贴出来了。我是属于“别有用心”加入的，并不为了学习某个具体算法，而是看到顺眼题目就试试怎么在没有思路的情况下解决掉它。常常一道题断断续续反复一两个星期。还好有这么个大部队，三天打鱼两天晒网的也还不至于完全扔下。
一点心得
本文只是个开篇，这里只是泛泛而谈。具体的心得可能结合题目实践过程才能完全说清。
爬出来
- 收集了很多失败。
虽然预料到不是那么容易，但是碰到的失败还是超出了预期。网上可见的TDD的例子中大多是怎么成功解决问题的。很少有失败的例子。失败而又不是用来证明TDD没用处的例子就更少了。
我在练习中，明显的感觉到了Uncle bob称之为“僵局”的模式。和同好交流时我们也会称作“掉坑”里去了。可以说，没有掉进坑里并爬出来的经历，基本还没有真的开始采用TDD。
从这个角度而言，展示具体的“掉坑”经历，并复盘分析有它特有的价值。 - TDD是更有条理的进行开发的方法，解决的是编码活动带来的额外复杂度，而不是解决问题本身。
换句话说，TDD是帮助你绑紧鞋带以免跑起来的时候绊倒自己，但是并不会让你从不会跑步变得会飞。
更多还是后面具体例子细说吧
练习回顾
目前总结了两道题目，第一篇特意详细描述了失败的经过。
[TDD磕算法] 排排队，吃果果（一）失败尝试
[TDD磕算法] 排排队，吃果果（二）先实现再优化
[TDD磕算法]排排队，吃果果（三）优化效率
