专业开发人员既要做好开发，也要做好沟通。
职业程序员会重视与团队及业务部门的沟通，确保这种沟通的准确、流畅。
7.1 需求的沟通
开发方和业务方之间最常见的沟通是关于需求的。业务方描述他们认为自己需要的东西，程序员按照自己理解的业务方表达的需求来开发。
7.1.1 过早精细化
- 不确定原则
- 预估焦虑
7.1.2 迟来的模糊性
避免过早精细化的办法是尽可能地推迟精细化。
7.2 验收测试
业务方与开发方合作编写的测试，其目的在于确定需求已经完成。
7.2.1 “完成”的定义
专业开发人员的“完成”只能有一个含义：完成，就是完成。
完成意味着所有的代码都写完了，所有的测试都通过了，QA和需求方已经认可。这，才是完成。
7.2.2 沟通
验收测试的目的是沟通、澄清和精细化。
7.2.3 自动化
验收测试都应当自动进行。原因很简单：要考虑成本。
专业开发员人认为，实现验收测试的自动化是自己的责任。
7.2.4 额外工作
不要把它们看作额外的工作，而应当看成节省时间和金钱的办法。
7.2.5 验收测试什么时候写，由谁来写
在理想状态下，业务方和QA会协作编写这些测试，程序员来检查测试之间是否有冲突或矛盾。通常会把测试交给专业分析员、QA甚至是开发人员。如果只能由开发人员来写测试，应当确保写测试的程序员与开发所测试功能的程序员不是同一个人。
验收测试应该越晚越好，通常是功能执行完成的前几天。
7.2.6 开发人员的角色
开发人员有责任把验收测试与系统联系起来，然后让这些测试通过。
7.2.7 测试的协商与被动推进
身为专业开发人员，与编写测试的人协商并改进测试是你的职责。
身为专业开发人员，你的职责是协助团队开发出最棒的软件。
7.2.8 验收测试和单元测试
单元测试是程序员写给程序员的，它是正式的设计文档，描述了底层结构及代码的行为。关系单元测试结果的是程序员而不是业务人员。
验收测试是业务方写给业务方的。它们是正式的需求文档，描述了业务方认为系统应该如何运行。关心验收测试结果的是业务方和程序员。
尽管两者测试的可能是同一个对象，其机制和路径确实不同的。
它们的主要功能其实不是测试，测试只是它们的附属职能。
7.2.9 图形界面及其他复杂因素
通过恰当的界面测试
应当尽可能地减少GUI测试。
7.2.10 持续集成
确保在持续集成系统中，单元测试和验收测试每天都能运行好几次。
立刻中止
持续集成不应该失败，如果失败了，团队里的所有人都应该停下手里的活，看看如何让测试通过。
7.3 结论
要解决开发方和业务方沟通问题，唯一有效的方法就是编写自动化的验收测试。
它们，就是无可挑剔的需求文档。