coding dojo 经验总结

周六参加Dojo ，氛围很活跃，嗨一下午，记录一下心得。

1. 搭建的环境TDD的环境很重要。

        自己一个人练习，环境熟悉即可； 当多个人练习的时候，需要一个环境来协作和展示。看到vim用的很溜的代码写起来感觉搜搜爽:)

        好几个人都提起cyber-dojo 是一个好工具。隔离环境准备问题，同时也是展示环境和协作的环境； 同时可以回放代码演化的过程。 果然是好东西大家都在用.

        另外看到spock 比junit 可读性好很多，下次还spock试试。

2. 反馈重要性

        TDD 之所以有效，是反馈的及时准确以及可稳定。 这个需要充分利用起来。

        测试编译失败反馈

        测试运行失败反馈

        更直接有效的大脑反馈， 是基于大脑预期反馈。 在新增测试，先不要运行测试！在运行测试之前，刻意暂暂停一下！ 留给大脑一点时间，让大脑判断当前的结果是什么？ 测试会成果吗？ 如果不会，测试会报什么错呢？ 然后运行，与大脑的预期结果判断，是否一致。 一致说明大脑的确掌控一切； 不一致，那么大脑某个地方纠正。  TDD希望根据反馈结构，让一切都在掌握只用

3. 测试用例分解

      测试如何分解，这个是TDD难点之一。 不能分解的测试 ，很难引导你驱动和演化出代码。 但是如何分解？可以分为下面几个case:

ａ．刚开始的时候，从哪里开始？ 第一个test case 怎么选取？从最简单的开始，能下到的最简单开始。 比如今天从一位数开始。

ｂ．当前情况下，下一个最小的测试用例是什么？这里面最关键词是“最小”，你认为下一个最小的用例是什么？这个需要练习，使得开发过程尽可能平滑

ｃ．当思路受阻时，怎么办？ 需要重新思考？回退？还是换一个case？这个下次留意。

d.    当前最小用例还是很复杂的时候？ 怎么办？ 需要简化一下用例，寻找一个中间的垫脚石，让当前的代码平滑演进？

当最后找不到失败的测试用例时，怎么保证结束（DoD）？ 做到测试用例的补重补漏？

4. 重构

TDD中另外一个难点就是重构？重构使得代码更加清晰，同时使得代码为未来增加新功能（跳跃）做好准备。

TDD中重构的两种类型

当识别出来坏味道的时候（重复，神奇数字，hard code，可读性不清晰，代码名字词不达意）， 需要重构，去除坏味道。

另外一种case，当需要添加新功能时候， 需要对现有的代码修改使得对下一个case做好准备。 比如（ 函数提提取，增加参数）

重构时间点

重构也对代码的修改，所以一定需要在测试通过的情况下进行。 有了防护网，避免引入潜在的错误，使得重构才有信心。

重构需要小步前行

重构是对代码的修改， 不管是对于去除坏味道，还是为未来做准备，都会引入bug，所以也需要小步前行。 如果改动太大，一次性改动导致太多的case失败，却很难定位到时哪里出错。这样花的时间去查找问题， 不如小步修改。 每一次修改一点，使得尽少出错，或者出错一眼就发现，使得对代码更有信心；同时将查找问题的时间换算成代码小步演进过程，这个也是一个划算的买卖。 这个也是一个难点。需要技巧，同时需要克制自己贪婪的内心，这个需要刻意练习。

比如要在Guess number，提取的循环的时候，先让当前的各种case可以跑过，延时提取的时候。（当另种不同类型的case合并，先等到两种类型case都完善后，在合并）

NOTE:学习优秀代码的演进

好的代码是如何写出来的？我们往往看到代码最终状态，却不知道代码是如何演变出来的？  Coding dojo给们这样一个好的机会。 不但可以看到同一个问题最后不同语言的不同实现，同样也可以看到代码是如何演化过来的。 一步一步代码从无到有，功能一点点如何增加，代码如何重构过来，测试如何驱动这些。使得陡峭的学习曲线平滑下来，大大降低学习难度。 更重要的是看到背后是如何思考的，问题是如何划分，功能时如何增加，代码如何重构，一步一步，这才是要学习的。也是dojo ，给集体学习的关键。dojo形式，用tdd方法结合pair-programming，这个感觉很嗨！

这是最后自己搭档小成迭代的代码 github，还是 挺满意的:)

另外感谢有激情新老朋友周末能参加，感谢老司机 @武可 带我们飞.