老师，任务列表里面的 Corner case 部分，除了代码审查发现，还有没有其他办法能够避免遗漏导致 BUG 呢？

测试代码也是需要重构的，之前一直没有意识到这点，觉得就算有点冗余也没关系。但实际上，只要是多余的代码就意味着团队的负债，会增加编译成本、跑用例的时间成本（这两项影响不大），更重要的是影响理解的成本，好的测试，就应该通过测试用例就能清晰的理解业务逻辑，而不是一行一行的去看代码。 学习了几讲后，越发觉得TDD其实是一种内功修炼，无论你的水平是多少，都是可以通过TDD不断精进，你对语言特性、设计模式、重构手法等等基本功，还有你对业务的理解，都通过一个个的用例、一次次重构体现出来。 TDD是一种对做事方法的极致拆分，一次只做一件事，思考业务逻辑时就不考虑实现和代码坏味道；编写业务代码时，也仅考虑能通过用例的逻辑；而重构时，也是不能改变原来的代码逻辑的。通过一个个极小粒度的操作，实现最终整体的协调，有种艺术的美感。

Go演示git提交记录: https://github.com/longyue0521/TDD-In-Go/commits/args Commits on Mar 28, 2022 ~ Commits on Mar 26, 2022之间的内容与本篇文章对应. 采用baby step每步都有提交记录可以对比学习. 如果觉得本项目对你有帮助,欢迎留言、star

这节课的视频看过来，感觉代码变得难以阅读了。 我觉得原因有两点： 1.因为对坏味道的延迟处理，让坏味道影响了代码的可读性。 2.因为对逻辑的构建是点式的而非线性的，导致思维在几个点之间跳跃而非循序渐进的，造成思维处在“先回忆再思考”的循环中。 不过也有可能是因为不是第一人称写代码，所以思维并不是完全跟上，不知道老师对这个问题怎么看。

三课观看下来有一种和老师结对的感觉，忽然明白了结对编程的相互学习过程比结果更最要，以往看到的代码包括开源项目的都已经是阶段性的结果，这个阶段结果的产生其实中间还一些子过程你是看不到的，就算你有设计文档和实现代码但是中间过程是缺失的，且这些中间过程也是无法从设计文档和结果代码反推出来的。中间的这些渐进过程才是内功心法。

真是跪着看完的

03 课 学习笔记 http://wyyl1.com/post/19/03/ 源码 https://github.com/wyyl1/geektime-tdd/tree/branch-03 摘要： 1. 测试代码需要重构 2. 提前将 Option 对象提取出 flag 的代码在 bad path 翻车了 3. 视频中代码的两个坏味道，期中之一：if 没有 “{}”。苹果公司的“GoTo Fail 漏洞”，就是因为没有括号引起的。 内容摘自：范学雷老师的专栏 极客时间 | 代码精进之路 | 02 | 把错误关在笼子里的五道关卡

这课最大的痛点之一是用了太多的java 专用技法,对c++用户特别不友好

代学习源码: https://github.com/ziyekudeng/my-geektime-tdd.git