1. 小游戏实践
2. Why？反馈 -> 自信心
   1. 人与机器之间的互动 => Feedback
      1. 多种编程方式
         1. 冥想
         2. 语音
      2. 即时的反馈
         1. 有学硬件的吗？
         2. 有学前端的吗？
      3. 敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。
      4. => 测试给予反馈，即时的自信心，单元测试离开发者的距离最近。
      5. 单元测试：用代码来检查代码，这是开发者获得反馈的主要来源。
   2. 怎样的程序才算正确？
      1. 能运行？ -> 人肉测它个一小时？
      2. 能实现功能？ -> 负负得正呢？
      3. 把 Bug 当 Feature？
   3. 讨论代码的易测性？可读性？
      1. 作为使用者，从调用的角度？
      2. 面向接口编程？
      3. 测试即文档
         1. 如何学习第三方工具库？
         2. 敏捷宣言：工作的软件 高于 详尽的文档
3. What？测试
   1. Feature Team
      1. 所有人都对质量负责任
         1. ThoughtWorkers 都是全栈
         2. 其他公司的测试加班时特别惨
      2. 最好的团队就像一个人一样
         1. Knowledge Sharing
         2. 团队的小而精干
         3. 相互信任
   2. 测试金字塔
      1. Why?
      2. 单元测试
      3. 集成测试
      4. 功能测试
4. How？手段
   1. 三部曲
      1. Given
      2. When
      3. Then
   2. 进阶
      1. Stub
      2. Mock
      3. DI
5. Refactoring
   1. 思想
      1. 仅仅掌握思想是没用的，学会所有的“坏味道”和对应的重构手法，先学会所有的招式，然后忘记，无招胜有招。
      2. 在设计前期使用设计模式常常导致过度工程，而设计模式为重构提供了目标，一次一小步修改代码，减少风险。单元测试和重构。
      3. 重构是在不改变软件可观察行为的前提下改善其内部结构
   2. 坏味道
      1. 从问问题出发？
      2. 写测试时的痛点
      3. 列出坏味道
   3. 手法
      1. 武林秘籍
      2. 无招胜有招
   4. 书籍
      1. 《重构：改善既有代码的设计》
      2. 《设计模式 : 可复用面向对象软件的基础》
      3. 《Refactoring to Patterns 重构与模式》
      4. 《Clean Code 代码整洁之道》
   5. 演讲 Tips
      1. 从需求变动出发（新需求）
      2. 场景化：无线电波
         1. deps
      3. 小步重构！保证结束前绿！
      4. 打蒙 -> 示例 -> 练习