对实例化需求方法的整理与思考

　　引言
　　“我希望这里能这样……”，“我希望这里能再增加点东西……”——在软件开发的世界，我们永远无法解决的一大难题，是客户纷繁复杂并且不断变化的需求。如何把需求映射为终的软件交付，是每一个软件开发方法都无法回避的核心问题。
　　领域驱动设计（Domain-Driven Design）通过专注领域核心、建立通用语言等手段，以及聚合、仓储等战术模式，很好地达到了去伪存真、化繁为简的目的，从而在团队协作、划分边界、建立模型等方面呈现出足够的优势。但是DDD的实践应用，非常依赖与客户沟通的技巧以及对领域知识的掌握。而这两点，都是需要一些实践经验积淀的，所以初入DDD并不容易。
　　实例化需求（Specification by Example，以下简称S&E），是我在学习BDD的过程中接触到的开发方法。之所以称其为开发方法，是因为它无法解决如何分析建模的问题，而主要回答了如何梳理用户需求Specification，并终将其实现为软件交付Delivery的整个过程。其擅长的，是捕获需求、确定验收标准。
　　那么，为什么我要把DDD与S&E相提并论呢？这是因为，DDD能帮助我们划分讨论的上下文、提取通用语言UL、建立软件模型，S&E则可以帮助我们梳理讨论的场景、验证模型能否达到交付要求、生成开发的相关文档。所以我个人认为，这两种方法能形成优势互补，帮助我们更容易地开发出“正确的软件”。
　　关于书籍
　　DDD之父Eric Evans的《Domain-Driven Design: Tackling Complexity in the Heart of Software》、Vaughn Vernon的《Implementing Domain-Driven Design》、Scott Millett的《Patterns， Principles， and Practices of Domain-Driven Design》，还有Jimmy Nilsson的《Applying Domain-Driven Design and Patterns: With Examples in C# and .NET》为我们提供了完整的理论和具体的实践。
　　现在通过我的书摘，再看看
　　Gojko Adzic的《Specification by Example: How Successful Teams Deliver the Right Software 》是怎么通过正反事例的对比，来逐步阐述Specification by Example这一方法的吧。
　　注：《Specification by Example》一书已有中译本《实例化需求：团队如何交付正确的软件》，由人民邮电出版社出版。不过我手里只有这浆糊一样排版的英文原版。所以，下文完全出自于我的个人理解，各种类比和小结将不断穿插其中。

　　看到这排版，我真心醉了
　　S&E过程概览
　　软件开发的压力主要来源于：时间——开发的期限越来越短，成本——维护的要求越来越高，变化——需求改变的频率越来越高。S&E采用一系列彼此衔接的处理模式及其产出的工件（artifact)，帮助我们顺利实现需求。其过程主要包括以下环节，并作为本篇各小节的目录：
　　· 根据业务目标Business Goal，划定问题域Scope
　　· 通过与客户的沟通协作，制定需求Specification
　　· 用具体的场景事例Example，阐明需求Specification的具体内容
　　· 提炼需求Specification，确定关键事例Key Example
　　· 在不修改需求的前提下，用自动化测试Automation来验证需求
　　· 在重构需求的同时，在系统与Executable Specification之间频繁地进行同步验证
　　· 利用工具，提取组织良好的、易于寻找的、前后一致的活文档Living Documentation
　　S&E关键过程示意图

　　建立“以文档为中心”的理念
　　目前实例化需求的过程现在有两种流行的模型：以验收测试为中心的ATDD，侧重于自动化测试，优点在于使开发目标更明确，并防止功能退化；以系统行为规范为主导的BDD，侧重于制定系统行为的场景，在客户与开发团队之间建立共识。这两种模型，各有长处、各有用途，所以无所谓孰优孰劣。我们关注的，是它们生成的活文档，这是实例化需求产出的好工件。书的第三章，率先回答了什么是活文档的问题，并倡导建立“以文档为中心”的理念。
　　为什么需要活文档？
　　维护开发文档总是一件费力不讨好的事情，却又总是不得已而为之，因为将来的重构与维护都需要以这样的一份文档为基础。这份文档需要能快速地勾勒出系统的轮廓，清晰地表达出系统主要的概念，准确地描述系统架构和模型的结构。关键的，这份文档必须是新的。所以，这份文档不仅要完整，还必须是“鲜活的”。
　　测试为什么可以作为文档？
　　自动化测试本身是按一定的逻辑编排的，所以具有一定的组织结构性。测试方法的名称，也可以看作是测试的一种“自描述”文本。所以这种结构性与自描述性，与开发文档的需求不谋而合，所以测试可以被当作文档的一种形式——“代码即文档”。
　　但是要注意，不能因此偏重于测试本身，而忽略了测试与需求之间的联系，使得测试变得臃肿和不易修改。ATDD的方法，往往过于注重编写和执行测试，因此容易写出不易维护的测试，导致有需求变化时，产生牵一发而动全身式的连锁反应，大量的维护与重构工作使得先前的测试工作变得得不偿失，因此要极力避免。
　　如何从测试得到活文档？
　　如果把带有Example的Executable Specification比喻为页面，那么整个活文档是由此构成的一整本书。利用Relish等BDD工具，我们可以把通过自动化测试验证后的Specification提取为HTML或者PDF等格式的文档系统，这甚至可以稍加修改作为用户手册使用。
　　综上所述，因为重构与维护的难度，我们需要一份组织良好的文档。BDD的自动化测试正符合文档的要求，而且恰好这种文档可以利用一些BDD工具从可以执行的Specification中提取出来，所以实例化需求方法可以视作一种建立在“以文档为中心”理念上的开发方法。
　　根据业务目标划定问题域
　　敏捷开发是以用户故事为核心的，所以故事讲得好不好至关重要。那么这个讲故事的责任究竟应由谁来承担？传统的软件开发，认为划分问题域、讲清故事是客户的事。对此，《BDD in Action》和本书的两位作者都反复强调，『不能交由客户去编写用户故事、用例清单等细节，否则等同于让客户去提供一个具体的、高层次的解决方案了。』所以，划分问题域、讲好用户故事，是开发团队的责任。在划定问题域这个环节，重点应该是引导用户弄清究竟需要什么，进而通过发掘现有业务的潜在，提出新的思路和新的方案。