敏捷的反馈

敏捷反馈

守护天使

Coding feedback.
为了应对代码的变化，你须要持续得到代码健康状态的反馈：他是在作你指望的事情吗？最近一次修改有没有无心中破坏了什么功能？为了确保全部功能都能正常工做，就须要自动化单元测试。

一些开发者会对“测试”这个词有意见，应把它看做是一个代码技术。用代码来检查变量的具体值，而不是手工检查那些感兴趣的变量。

只要有了单元测试，就让到他们自动运行，也就是每次编译或者构建代码的时候，就运行一次测试。把单元测试的结果看做是和编译器同样——若是测试没有经过，那就像变异没有经过同样糟糕。

接下来就是在后台假设一个构建机器，不断获取最新版本的源代码，而后编译代码，并运行单元测试，若是有任何错误它会让你及时知道，这是最容易修复也是成本最低的时候。

具体技巧

• 单元测试是优质股，值得投资。但一些简单的属性访问方法或者价值不大的方法，是不值得花费时间进行测试的。
• 人们不编写单元测试的不少借口都是由于代码中的设计缺陷。一般，抗议越强烈，就说明设计越糟糕。
• 单元测试只有在达到必定测试覆盖率的时候，才能真正地发挥做用。你可使用一些测试覆盖率工具，大体了解本身的单元测试的覆盖状况。
• 不是测试越多质量就会越高，测试必需要有效。若是测试没法发现任何问题，也许它们就是没有测试对路。

先用它再实现它

咱们的业务是要创造出能调用的API和可使用的接口。这就是说，你在说服其余人使用它以前，先得让本身切实地使用这些接口。事实上，在你刚作完设计但尚未完成后面的实现的时候，应该使用它。这个可行吗？

Write test before writing code.
使用被称为TDD（Test Driven Development，测试驱动开发）的技术，你老是在有一个失败的单元测试后才开始编码。测试老是先编写。一般，测试失败要么是由于测试的方法不存在，要么是由于方法的逻辑还不足以让测试经过。

先写测试，你就会站在代码用户的角度来思考，而不只仅是一个单纯的实现者，这样作是有很大区别的，你会发现，由于你本身要使用它们，因此能设计一个更有用、更一致的接口，除此以外，先写测试有助于消除过分复杂的设计，让你能够专一于真正须要完成的工做。

消除那些尚未编写的类，这会很容易地简化代码。相反，一旦你已经编写了代码，也许会强迫本身保留这些代码，并继续使用它，即便代码已通过期做废好久了。

Good design doesn’t mean more classes.
当你开发设计面向对象系统的时候，可能会迫使本身使用对象，有一种倾向认为，面对对象的系统应该由对象组成，咱们迫使本身建立愈来愈多的对象类，无论他们是否真的须要。添加无用代码老是很差的想法。

具体技巧

• 不要把测试优先和提交代码以前的测试等同起来。测试先行能够帮助你改进设计，但你仍是须要在提交代码以前作测试。
• 任何一个设计均可以被改进
• 你在验证一个想法或者设计一个原型的时候，单元测试也许并不适合。可是，玩意这些代码不行仓促演变成了一个真正的系统，就必需要为它们添加测试（可是最好能从新开始设计系统）。
• 单纯的单元测试没法保证好的设计，但它们会对设计有帮助，会让设计更加简单。

不一样环境，就有不一样问题

也许，你会要求测试团队在全部支持的平台上进行测试。若是它们是手工进行测试，可能并非最可靠的测试办法。咱们须要更加面向开发者的测试办法。

你已经编写了单元测试，测试你的代码。每次在修改或者重构代码的时候，在提交代码以前，你会运行测试用例。那么如今所要作的，就是在各类支持的平台和环境中运行这些测试用例。

Automate to save time.
可是，也许你已经有时间压力了，所以，你怎么可能有时间在多个平台上运行测试呢？这就要靠持续集成来拯救了。咱们在前面的保持能够发布中学过，用一个持续集成工具，周期性地从源代码控制系统中取得代码，并运行代码。若是有任何测试失败了，他会通知相关的开发者。通知方式多是电子邮件、页面I、RSS Feed或者其余一些新颖的方式。要在多个平台上测试，你只要为每一个平台设置持续集成系统就好了。当你或者同事提交了代码，测试会在每一个平台上自动运行。

具体技巧

• 硬件比开发人员的时间便宜。但若是你有不少配置，要支持大量的平台，能够选择哪些平台须要内部测试。
• 软件在不少平台上出现Bug极可能只是由于栈布局的差别、机器字大小端的不一样所致。所以，即便用Solaris的用户比用Linux的少不少，你也仍然要在两个系统上都进行测试。
• 你不但愿由于一个错误而收到5次通知轰炸（这就像是双重征税，会致使电子邮件疲劳症）。能够设置一个主构建平台或者配置，下降其余构建服务器的运行频率，这样在它失败的时候，你就有足够的时间来修复主构建平台。或者汇总全部错误报告信息到一个地方，进行统一处理。

自动验收测试

关键业务逻辑必需要独立进行严格的测试，而且最后须要经过用户的审批。但你也不可能拉着用户，逐一检查每一个单元测试的运行结果。实际上，你须要能自动比较用户指望和实际完成的工做。

有一个办法可使验收测试不一样于单元测试。你应该让用户在没必要学习编码的状况下，根据本身的须要进行添加、更新和修改数据。你有不少方法来实现它。

FIT，即集成测试框架，它很实用，能够更容易地使用HTML表格定义测试用例，并比较测试结果数据。使用FIT，客户能够定义带有新功能的使用样本。客户、测试人员和开发人员（根据样本）均可以建立表格，为代码描述kennel的输入和输出值。开发人员会参照带有正在开发的代码结果的FIT表格中的样本编写测试代码。测试结果成功或者失败，都会显示在HTML页面中，用户能够很方便地查阅。

若是领域专家提供了业务的算法、运算或者方程式，为他们实现一套能够独立运行的测试。要让这些测试都成为测试套件的一部分，你会在项目生命周期中确保持续为它们提供正确的答案。

具体技巧

• 不是全部客户都能给你提供正确的数据。若是它们已经有了正确的数据，就根本不须要新系统了。
• 你也许会在旧系统中发现之前根本不知道的bug，或者之前不存在的真正问题。
• 使用客户的业务逻辑，可是不要陷入一望无际的文档写做之中。

度量真实的进度

时间的消逝能够证实：判断工做进度最好是看实际花费的时间而不是估计的时间。
咱们不该该去计算工做量完成的百分比，而应该测定还剩下多少工做量没有完成。

在你最后真正完成一项任务时，要清楚知道完成这个任务真正花费的时间。奇怪的时，它花费的时间极可能要比最初估计时间长。没有关系，咱们但愿这能做为下一次的参考。在为下一个任务估计工做量时，能够根据此次经验调整评估。你的评估会波动一段时间，但随着时间但推移，你但评估会与事实接近，你也会对任务所花费但时间有梗清楚的认识。

若是能一直让下一步工做时可见的，会有助于进度度量。最好多作法就是使用待办事项backlog。当添加新任务的时候，先排列它们的优先级，而后加入到待办事项中。你也能够有我的的待办事项、当前迭代的待办事项（工做项）或者整个项目的待办事项（项目进行阶段）。

具体技巧

• 6分钟做为一个时间单位，它的粒度太细了，这不是敏捷的作法。
• 一周或者一个月的时间单元，它的粒度太粗了，这也不是敏捷的作法。
• 关注功能，而不是日程表。
• 若是你在一个项目中花费了不少时间来了解你所花费的时间，而没有足够的时间进行工做，那么你在了解你所花费的时间上花费的时间就太多了。听懂了吗？
• 一周工做40个小时，不是说你就有40个小时的编码时间。你须要减去会议、电话、电子邮件以及其余相关活动的时间。

倾听用户的声音

It is a bug.
当出了错误，你要尽量地提供详细信息。黑屏和含义不明的退出按钮说很不友好的行为。更糟糕的是，在获得用户反馈的时候，还嘲笑用户愚蠢，而不去真正地解决问题。

无论它是不是产品的bug，仍是文档的bug，或者是对用户社区理解的bug，它都是团队的问题，而不是用户的问题。

咱们花费了很大的精力从单元测试之类的代码中得到反馈，但却最容易忽略最终用户的反馈。你不只须要和真实用户（不是他们的产品经理，也不是业务分析师之类的代理人）进行交谈，还须要耐心地倾听。

即便他们说的内容很傻！

具体技巧

• 没有愚蠢的用户
• 只有愚蠢自大的开发人员
• “它就是这样的。”这不是一个好的答案。
• 若是代码问题解决不了，也许能够考虑经过修改文档或者培训来弥补。
• 你的用户有可能会阅读全部的文档，记住其中的全部内容，但也可能不会。