上周四的中午饭后，我们team坐下来完成了一次Code Kata练习。跟之前的几次邀请PwC team同事过来pair和coach不同，这次是我们组自己内部完成一次练习，题目来自Yuheng之前的一个练习：文曲星上的猜数字游戏。
题目规则很简单：
- 游戏开始后，系统会随机给出四个不重复的数字。由用户输入自己猜测的四个数字。
- 如果数字猜对而且位置也对，就是1一个A。
- 如果数字猜对但位置不对，就是一个B。
- 返回结果是如“2A1B”这样的字串。
- 猜错6次，游戏提示结束。重来。
开始提出的要求简单：用TDD驱动出实际代码。
大家抽签后开始pair，Yuheng还会一边计时一边催促，pair的气氛基本保持紧张有序。
在我和XuChen pair开始代码后，我们很容易写出第一个测试1，期望返回结果是”4A0B”，最简单的代码实现让测试变绿。
当我们试图写下第二个测试2，试图期望返回结果是“2A1B”时，我们发现不得不面对如何这个游戏规则的最核心算法，但可惜的是，猛然间对这个算法没有头绪。
局面一时僵住，停顿了有两分钟。
直觉和一点经验告诉我们，这时该拆解任务了。很容易想到，如果计算出几个A和几个B是很直白的拆分。
我们可以很容易写出一个测试3，测试猜测的四个数字跟事先给定的四个数字相比，有几个A类数字（循环比较），我们称之为perfect number。
也很容易写出另外一个测试4，测试猜测的四个数字跟事先给定的四个数字相比，有几个B类数字（在上个算法的基础上再循环比较），我们称之为good number。
写完针对测试3和4的实现代码，我们发现我们已经完成了最基本的算法，功能完成了。剩下的是重构代码。
从我们这次的经验看，我有一些收获和心得：
- 测试就是代码的设计，你看测试3和4导致的结果就是我们有了对应的两个计算方法。你打算怎么测，你的实现代码就会是怎样的。
- 印证了在Wikipedia中那段话，pair programming尤其适合面对一些challenging的任务（至少开始的时候是）。
- 分解任务是王道。我们在不同的level拆分任务，从story拆分成task，从大问题拆分成小问题，莫不如是。
- 囿于经验，不期望由端到端的测试能逐步甚至一下子推导出完整、完善的代码实现。而这样的练习，恰恰是我们锻造自己经验必不可少的过程。
我们在实现代码时，仍然欠缺的是：
- 对于测试方法名的命名，不够清晰直白。
- 对于算法代码的实现，简单粗糙，还需要重构。
