TDD中的一小步 2-->1+1

小步

小步进行（Baby steps）是TDD开发中非常重要的理念。

• 小步增加测试，确保了不会一次引入过多变更。以免一不小心扯了蛋。:D
• 小步通过测试，确保了最快最直接的从红灯转为绿灯。避免前期过度设计，以及随之而来的无测试的实现代码。
• 小步重构， 确保了安全平滑的改善代码结构。

在整个TDD“红灯->绿灯->重构”的循环中，小步提供了快速反馈让我们随时检验代码行为，并在出错的第一时间进行修正。另一方面也促使我们“一次只做一件事”，将一个较为复杂的问题分解开来逐步解决。

僵局

看起来很简单是吧，但是现实往往是骨感的。在学习TDD的过程中，我们经常会发现小步成为了一大难点。一开始的红灯然后hardcode绿灯还算简单。之后，要么反复的小步踏步，要么对这种小步探索丧失信心，重新回到了 长时间预先设计 -> 大改动 -> 调试 的节奏中。
对这个问题，Unclue Bob提出了一个指导意见， Transformation Priority Premise （代码变换优先次序）简称 TPP。由于整个的优先列表比较复杂，而且还有些可商榷的地方，今天在这里并不打算详细介绍。有兴趣的同学可以看看文末链接。这里只对比最近一次coding dojo的例子，分享一下这个原则对小步练习的启发。

蠢代码 聪明代码

在第一个“红灯->绿灯”循环后，有一个问题就摆在了程序员面前：既然要求最快的通过测试，那么为什么不一直hardcode来通过测试呢？
以我们所做的“罗马数字转换为整数”的Kata为例，在一开始hardcode

if(roman.equals("X")) {
return 10;
}
if(roman.equals("V")) {
return 5;
}
if(roman.equals("I")) {
return 1；
}

到

...
if(roman.equals("II")) {
return 2;
}

之后，为什么不写3千句if来解决这个题目呢？
其实我们心里都明白，一句永远返回一个值的代码太蠢了。它并不真正“理解”并解决问题，我们的目标是要写一段“聪明”的代码来真的解决它。难点在于，我们习惯于一开始就寻找“聪明”的方案，从问题的“本质”去解决。一旦刻意缩小步伐，先写下一句蠢代码，却发现找不到一条路把它逐步变的聪明起来。

constant -> constant+

这里就引入了TPP中的一步，constant -> constant+
当我们开始写II转换为2的逻辑时，首先增加了一个硬编码的分支来通过测试
这时，可能我们心里会觉得有一些不对，感觉并没有真正在解决这个问题。那么，如何开始让代码向”真正“的代码演进呢？
下面就是采用了constant -> constant +规则来重构后的代码

if(roman.equals("I"+"I")) {
return 1+1;
}

哇哦……
好吧，其实好像没什么大不了的嘛。从编译运行来说，"I"+"I"和1+1很可能会被编译器直接优化成为常量"II" 和2，也就是说这么改写对机器来说，根本就是一样的嘛。
但是代码是给人看的。
这个变换的最大意义，在于减少了代码中的知识。

知识

知识，在日常生活中是个很好的词。“知识就是力量”，“知识改变生活”，见多识广是美德。
然而，软件中的知识却并非如此。对于代码而言，知识意味着无法用逻辑解释的事情。比如为什么罗马人用I表示1，而不是用Y。这是代码无法回答的问题。一个知识对于代码而言就是一个依赖或者假设。怎么处理这些依赖和假设是软件设计的关键问题。

在代码世界中“你知道的太多了”可能是更合适的格言

以非常常见的两个设计原则为例：

1. 消除重复 （DRY）：这条规则往往被理解为消除重复的代码。着眼点在于避免重复劳动。比如上面例子中“II”改写为"I" + "I"后，可能很快就会有人意识到"I"可以提取替换来消除字面量的重复。然而比这个更重要的是，消除知识的重复。也就是说对于每个知识，应该有且只有一个地方对其进行表述。
2. 单一职责：这里的职责，往往也被局限在代码功能方面。对于不怎么需要编码的事情，往往就忘记它也可能和职责相关了。比如当前时间，比如pi=3.14。事实上，职责最重要的一点就是知识的所有权。对于每项知识，应该有一个所有者对它“说了算”，系统的其它部分都听它的，这样才能保证所有相关于这个知识的改变都局部化在这个单元之中。

我们再回头以知识的视角来看2->1+1的这一次变换。前面的I->1,V->5,X->10……是罗马数字本身所固有的知识。软件中必须要写下处理这些知识的代码，当然，可以写的比一堆if优雅很多，不过这是另一个话题了。
然而 II->2 却不同。它是 I->1以及数字组合逻辑的派生结果。简单的增加一句if是向系统中增加了一个知识，而这个知识本身是可以消除掉的。
通过把本来看似一整块的常量写成常量的组合，让本来隐含的知识重复变成了明显的代码重复。为后续的提取常量/变量等后续重构开辟了道路。

参考资料

TPP： https://blog.8thlight.com/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html
漫画版： http://blog.8thlight.com/uncle-bob/2013/05/27/TransformationPriorityAndSorting.html