守护天使

使用自动化的单元测试，好的单元测试能够为你的代码问题提供及时的警报。如果没有到位的单元测试，不要进行任何设计和代码修改。

平衡的艺术：

人们不编写单元测试的很多借口都是因为代码中的设计缺陷。通常抗议越强烈，就说明设计越糟糕

不是测试越多质量就越高，测试必须要有效，如果测试无法发现任何问题，也许他们就是没有测试对路

先使用它再实现它

利用测试驱动开发作为设计工具，这样只有具体理由才开始编码，可以专注于设计接口，而不会被很多实现细节干扰

不同环境，就有不同问题

使用持续集成工具，在每个支持的平台和环境中运行单元测试，要积极寻找问题，而不是等问题来找你

自动验收测试

为核心业务逻辑创建测试，让你的客户单独验证这些测试，要让它们像一般测试一样可以自动运行。

度量真实地进度

使用代办事项，使得下一步工作是可见的，有助于进度度量，而不是按照百分比安排。不要用不恰当的度量来欺骗自己或者团队，要评估那些需要完成的待办事项。（每天列清单果然是好习惯，再加番茄工作法，用来计时）

时间单元不要太细或者太粗，6分钟或者一周都不合适（所以番茄工作法的半个小时，一个小时是OK的）

关注功能，而不是日程表

一周工作40个小时，实际上编码时间不足40个小时，还有会议、电话等时间

倾听用户的声音

每个用户抱怨背后都隐藏了一个事实，找出真相，修复真正地问题。

书中讲到没有愚蠢的用户，只有愚蠢自大的开发用户。

“它就是这样的。”这不是一个好答案

如果代码问题解决不了，也许可以考虑通过修改文档或者培训来弥补

用户可能阅读所有文档，但是也可能不会。

参考链接

评论可见，请评论后查看内容，谢谢！！！评论后请刷新页面。