观看“ 两个Daniel结对写 Game of Life ”

观看两个Daniel结对编程的TDD 开发，两位小步快走，实现这个Game of life。期间精益求精，对于看点，小部分解，是重点. 软件开发不仅仅看到过程，同样也要看代码的实现过程是如何演化的。感谢两位Daniel. 

视频分为三段地址：1, 2,3

1. 软件开发中反馈很重要。单元测试，TDD 开发， CI/CD 都是利用反馈机制，帮助我们早点发现问题，尽可能帮助定位问题。 那么反馈的极限是什么？ 实时反馈，或接近实时反馈。 写下代码，对不对？ 如果不对，哪一行点出错甚至告诉你哪一行出错？实时的告诉你答案，开发的过程挑战就会降低很多。  要得到如此准确的反馈，那么就需要每一次变化尽可能的小。 这样,如果出错了，就直接定位到刚才修改的地方.  免去去debug，查看log的耗时和开发风险。这就是基于反馈的小步快走开发模式。

2. 如何做好TDD 开发

先介绍指导原则

Always drive code from requirement - 代码是从需求一步一步推演出来

Limit red phase - 尽快让失败的测试用例通过，从而尽量缩短代码RED状态的时间

Improve design only when code base is safe - 只有在代码安全的状态下，才去优化和改进设计

测试用例就是需求，没有测试没有新代码。 尽可能让失败测试通过，尽可能少的代码，哪怕是hardcode。 缩短红色时间，就是缩短代码有测试用例失败， 让进可能多的时候在安全状态下。重构和修改应该是在安全情况下进行。 

 2.1  从哪里开始。  第一个test case 是从哪里开始？ 从最简单的开始，从最原始的开始。 比如 Game of Life 游戏中，最简单的case就是只有一个元素的二维数组。 

其实这个想想也是合理的。 软件开发当作一个生长的过程，从开始小苗，一点一点长大。 起点应该就是最简单的状态开始，然后随着test case的增多，功能越来越多。所以开始从最简单的开始，甚至是hard code 开始。

 2.2  如何迭代。

TDD开发的一个流程如下图所示。先写一个test case， 然后编译通关过； 写尽可能少的代码使得测试通过； 然后重构代码和测试代码，最常见的就是去除重复；然后开始下一次迭代。

但是视频里面有个感触，印象特别深刻， 两次反馈。 在写下一个test case 后运行之前，自己先判断一下运行结果。可以通过吗？ 为什么？不可以吗？错误又是什么？ 和传统的TDD 比起来。

构造新测试用例 ---->计算机返回执行结果 -----> 然后修改代码使得通过；

构造测试用例 ---> 大脑去想在当前的代码下，这个case会出现什么结果 -----> 运行结果与大脑模型比对 ----> 和预期一样吗；不一样估计大脑想的那个地方漏掉？（纠正，这个大脑模型反馈） -----> 修改代码使得测试通过（第二次反馈）。 

这两个模型，下面这个反馈比上面的多一次，同时会感觉到对代码更加了解。这个样的反馈直接到大脑，反馈更有针对性，更有力，对于代码感觉更有控制力。 

TDD

 2.3  重构和跳跃

跳跃，是指代码增加增加新功能，会破坏当前代码行为。好的是已有代码，已经有测试保护，安全网。这个时候如果破坏会被早点发现。同时，这个跳跃步伐很小，就改一个点，甚至是一行代码，那么很容易定位。 关键问题是让每一步跳跃尽可能的小，這就需要分解问题。 下面一节会谈到。

重构，修改代码状态，有两种情形。 一种去除坏味道。 另外一种为适应跳跃为下一步迭代做准备，使得当前的代码适应新的变化。 重构不应该修改代码的行为。

 2.4  复杂问题分解， 垫脚石。

如果问题比较复杂，跳跃太大，往往出问题，即使被测试用例发现，也很难知道哪个地方出错。 这个时候，就是分解步伐太大。需要找再一次分解，简化，甚至找一个垫脚石。 自己在做这game of life 游戏的时候，跳跃步伐太大（从一纬到二维，一次直接支持复活， 斜方向的支持，循环对所有元素迭代） ，结果发现出错，眼睛很难找不出来错误。这时候就有诱惑去用IDE去调试。

视频里面，将这个问题简化。

a. 先不考虑复活规则；

b. 然后简化只考虑斜线的一个方向；

c. 再次简化，不考虑斜线方向，只要引入二维。

d. Hard code 实现这case。

e. 为未来（下一次）重构，提取参数。

这样看起来有点琐碎，有点慢。 但是的确出错的的更显大大降低，同时使得结果可预期。每一次只做一件事，每一次修改只针对一个点，测试用例已经覆盖了。代码的质量有保证。这个过程中，为了分解，我们构造出来的中间过程，我称之为垫脚石，使得代码的跳跃变的平滑。

NOTE：

1. 一些坏的信号。 发现错误，结果不知道哪里出错，想不出来。 同样，需要借助debug来调试 ，这些都表明步子可能太大，需要分解简化甚至是垫脚石参加2.4

2 跳跃前的状态是安全的（绿色，所有已有的test case都通过）。只有在安全的情况下修改，每次只修改一个点，不受其他干扰。

3. 让代码处于不安全状态尽时间尽可能短。