Python 高手编程系列八十五：文档驱动开发

与其他语言相比Python 中的 doctests 是一个真正的优势。事实上文档可以使用代码示例这些代码示例也可作为测试运行这改变了 TDD 的开发方式。例如文档的一部分可以通过在开发周期中的 doctests 来完成。这种方法还确保所提供的示例总是最新的并且能够真正工作。通过 doctests 而不是常规的单元测试来构建软件称为文档驱动开发Document-Driven DevelopmentDDD。开发人员在编写代码时用简单的文字解释代码正在做什么。写一个来历在 DDD 中可以通过构建一个代码的来历来编写 doctests来历主要说明代码如何工作以及何时应该使用代码。原则上用简单的文字描述就可以然后几个代码使用示例分布在整个文本中。一个好的做法是开始写代码如何工作的文本然后添加一些代码示例。看一个真实的 doctests 的例子让我们看看 atomisator 包参考 https://bitbucket.org/tarek/atomisator。其 atomisator.parser 子包在 packages/atomisator.parser/atomisator/parser/docs/README.txt 下的文档文本如下所示atomisator.parserThe parser knows how to return a feed content, withtheparsefunction, available as a top-level function::from atomisator.parser import ParserThis function takes the feed url and returns an iteratorover its content. A second parameter can specify a maximumnumber of entries to return. If not given, it is fixed to 10::import osres Parser()(os.path.join(test_dir, ‘sample.xml’))resitertools.imap …Each item is a dictionary that contain the entry::entry res.next()entry[‘title’]u’CSSEdit 2.0 Released’The keys available are:keys sorted(entry.keys())list(keys)[‘id’, ‘link’, ‘links’, ‘summary’, ‘summary_detail’, ‘tags’,‘title’, ‘title_detail’]Dates are changed into datetime::type(entry[‘date’])稍后doctest 将演变以考虑新的元素或所需的变化。对于想使用这个包的开发者来说这个 doctest 也是一个很好的文档所以应该发自内心地改变对 doctest 的用法。在文档中写测试的常见缺陷是将其转换为不可读的文本。如果发生这种情况应该把这些测试视为文档的一部分。有人说一些完全通过 doctests 工作的开发人员通常将他们的 doctest 分为两类可读的和可用的所以它们可以是包文档的一部分而那些不可读的只是用于构建并测试软件。许多开发人员认为为了后者应该放弃 doctests 以支持常规单元测试。其他人甚至使用专门的 doctests 修复 bug。所以doctests 和常规测试之间的平衡是一个饱受争议的问题这取决于由团队只要发布的 doctests 部分是可读的。小结本章提倡使用 TDD并提供了很多相关的信息。● unittest 陷阱。● 第三方工具nose 和 py.test。● 如何构建仿真和模拟。● 文档驱动开发。由于我们已经知道如何构建、打包和测试软件在接下来的两章中我们将关注如何找到性能瓶颈的方法并优化你的程序。优化——一般原则与分析技术“我们应该忘记小的效能大约 97%的情况过早优化是万恶之源。”—Donald Knuth本章是关于优化的并且提供一套一般原则和分析技术。它给出了每个开发人员应该注意的 3 个优化规则并提供优化指南。最后本章会关注如何找到瓶颈。3 个优化规则不管结果如何优化需要付出一些代价。当一段代码正常工作时如果不去管它而不是试图花费很多成本使其更快它可能有时运行的更好。进行任何类型的优化时请注意以下几个规则。• 首先要能工作。• 从用户的角度考虑。• 保持代码的可读性。