高效程序员的45个习惯 5.敏捷反馈
一步行动，胜过千万专家的意见。
Tips
让“守护天使”来监督你的代码
先用它再实现它
不同环境，就有不同问题
通过自动验收测试来保证代码是正确的
度量真实的进度
倾听用户的声音
单元测试
单元测试只有达到一定测试覆盖率的时候才能真正地发挥作用。
下面是单元测试的一些好处：
- 及时提供反馈，特别是在你修改或者重构了代码的时候
- 让你的代码更加健壮
- 有用的设计工具，这一点平时可能没怎么注意，意识是说单元测试可以有助于实现简单的、注重实效的设计
- 让你自信的后台，这点平时应该都有体会吧
- 解决问题的探测器
- 可信的文档，有助于你理解系统
- 学习工具，有助于理解API的行为
先用它再实现它
这个主要是将TDD，测试驱动开发，感觉就是只在有具体理由的时候才开始编码，你可以专注于设计接口，而不会被很多实现的细节干扰。
不同的环境就有不同的问题
使用自动化会节省时间 - Automate to save time
阅读Martin Fowler 写的一篇重要的文章Continuous Integration
，http://www.martinfowler.com/articles/continuousIntegration.html
通过持续集成在多个平台上运行测试。
在前面我们提到“保持可以发布”中学过，用一个持续集成工具，周期性地从源代码控制系统中取得代码，并运行代码。如果任何测试失败了，它会通知相关的开发者。
自动验收测试
为核心的业务逻辑创建测试，让你的客户单独验证这些测试，要让它们像一般的测试一样可以自动运行。
度量真实的进度
不要用百分比来描述进度，随意用一个比率进行度量是没有意义的，我们应该测定还剩多少工作量还没有完成。
如果你最初估计这个任务需要40个小时，在开发了35个小时之后，你认为还需要另外30个小时的工作。那就得到了很重要的度量结果（这里诚实非常重要，隐瞒真相毫无意义）。
Scrum方法中的sprint
在Scrum开发方法中（Sch04），每个迭代被称作sprint，通常为30天时间。sprint的待办事项列表是当前迭代任务列表，它会评估剩下的工作量，显示每个任务还需要多少小时可以完成。
每个工作日，每个团队成员会重新评估完成一个任务还需要多少小时。不管怎么样，只要所有任务的评估总和超过了一个迭代剩余的时间，那么任务就必须移到下一个迭代中开发。
如果每月还有一些剩余的时间，你还可以添加新的任务。这样做，客户一定会非常喜欢。
倾听用户的声音
用户就是会抱怨。这不是你的过错，是用户太愚蠢了，连使用手册都看不懂。它不是一个bug，只是用户不明白如何使用而已。他们本应该知道更多。
每一个抱怨的背后都隐藏了一个事实。找出真相，修复真正的问题。
对客户的那些愚蠢抱怨，你既不会生气，也不会轻视。你会查看一下，找出背后真正的问题。
没有愚蠢的用户。
只有愚蠢、自大的开发人员。
“它就是这样的。”这不是一个好的答案。
如果代码问题解决不了，也许可以考虑通过修改文档或者培训来弥补。
你的用户有可能会阅读所有的文档，记住其中的所有内容。但也可能不会。
