很早之前就有了和同屋同学（国内大型IT企业员工）结对的想法，很想看看和一个从来没用过测试驱动开发（TDD）和结对编程（Pair）的人一起Pair是什么效果。正好最近进行郑大晔校，面对的都是白纸一张的应届毕业生，后期培训也会需要和新人Pair的经验，所以这次决定试验一下。
周日起了个大早，和同屋一起去吃胡辣汤，好久没吃了，美美的吃了一顿，吃饱了才能干活么。
回家后就开始Pair，题目是上次在办公室参加Code Jam的出租车题，目标完成两个需求，分成两次迭代，时间大约1个半小时。
第一个迭代
按照TDD的原则，我们首先根据需求写出了测试，然后驱动出产品代码，介绍了TDD的节奏（红->绿->重构->绿），以及IntelliJ一些简单的快捷键使用。
我首先写出测试，然后强调使用最简单的方式通过测试，紧接着在进行产品代码的重构。接着再写出第二个测试，让他来实现测试，并且提出由他主导来重构代码。
接下来由他来写出新测试，我来实现，测试通过后一起重构代码，重构了之前他写出的不是很干净的代码。
总体来说完成了第一个迭代的需求，并且通过频繁交流和让他亲自写代码来提升参与感。
第二个迭代
提出进一步的需求，并且不自觉的让他完成写测试->测试红->实现测试->测试绿->重构->测试绿的整体流程，基本上完成了新需求。
由于第二步需求修改地方较多，我们写出新的测试，并且修改了之前的测试，在让测试通过的过程中，我依然建议使用“简单粗暴”的方式通过测试，然后他主动意识到要进行重构。
在重构过程中，我们进行了很多讨论，比如他提到变量名过长，我们经过讨论意识到：通过变量已经不足以表述，所以使用方法来描述刚才的代码。最后随着我们将最后一个“魔法数”（介绍）消除，代码基本上处于一种干净的状态。
回顾
不足之处：
- 我有些时候不是很耐心，揭晓答案过快，不如由他自己得出答案效果好。
- 苹果笔记本上的特效过多，比如F12进入Dashboard，hotcorner锁屏等，有些影响参与者的情绪。
- Windows上面的Ctrl 快捷键在Mac OS上面已经是command了，参与者很不适应。
做得好的：
- 很好的介绍了TDD和Pair。
- 让参与者感受到了TDD的节奏，有了测试保证重构结果，可以信心满满的重构代码。
- 让参与者看到了有很多很好的开发习惯，最重要的就是快捷键的使用。
- 激发了参与者的学习兴趣，参与者表现出强烈的学习意愿，包括TDD，快捷键等
问题：
- 因为参与者的工作环境不同，那么如何将TDD应用到平时的工作中？