《测试驱动数据库开发》——1.1 为何改变书的内容

  1. 云栖社区>
  2. 博客>
  3. 正文

《测试驱动数据库开发》——1.1 为何改变书的内容

异步社区 2017-05-02 15:37:00 浏览784
展开阅读全文

本节书摘来自异步社区出版社《测试驱动数据库开发》一书中的第1章,第1.1节,作者:测试驱动数据库开发,更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.1 为何改变书的内容

测试驱动数据库开发
本书最初的书名是《敏捷数据库开发:从需求到交付》。到现在书名和内容都己经变了好几次。

在读者反馈和自我启发的双重作用下,本书经历了几次激进的蜕变,由开始的一本主要讨论开发过程并稍带讲一点技术的书,转化为讨论 TDD 的差异如何影响敏捷数据库开发过程的书,然后最终将有关团队级别的开发过程内容完全去除而成为今天这个样子的书。

为什么我几次变化本书的方向?主要是因为开发人员学到的有关敏捷软件开发的几乎所有有关过程管理(process-management)的知识,对任何领域都是普遍适用的,通常情况下甚至适用于硬件设计。我过去写的很多东西,要么是对别人写过的内容的重复,要么就是向人们说教那些他们已经接受了的东西,再写这些东西注定都是无效的。对于那些在构建数据库时寻求如何做敏捷开发的建议的人,建议先学如何做敏捷软件开发,然后再将其运用在数据库上。

当然,如果你做数据库开发,你会发现你需要学习如何做TDD。要想让任何敏捷开发的努力取得成功,测试驱动开发的法则是绝对至关重要的,并且我相信是无可争议的,你需要一系列可执行的规格说明来告诉你,你所做的变化是否安全。如果没有这样的规格说明,你就不可能让敏捷有成效。

事情在这里变得有些棘手,将测试驱动开发运用到传统面向对象开发和数据库开发中会有很大的不同。也就是说,尽管 TDD 的原则普遍适用,但是为构建应用程序和中间层逻辑而开发的相应的实践,却不总会完美地被转换到数据库领域中。

另外,即使你的团队还没有准备好拥抱敏捷软件开发,你也能使用测试驱动开发。

1.1.1 每天敏捷都在逐步地入侵我们的领域

文明的潮汐控制着人们做事情的方式。当这个大潮退去时,我们集中起来建立指挥和控制结构,并试图在大批量和排长队的现象中找到效率。当潮水涨回来时,我们又打破那些结构,开始将控制权交到“平常”人的手中,并且试图在那些离问题最近的人所快速做出的决定中找到效率。

潮水正在涨回来,在本书写作期间,潮水也将可能退去。

对于我们来说,潮水涨潮是否正确,就跟站在海滩上的人关心水冲到岸上是否正确一样,是无关紧要的。波浪已经来临,不管你是否喜欢,最好做好准备。因为开发人员不得不用更小的增量和更快速地交付价值的方式来改善开发工作,因为人们已经不愿意经过漫长的等待才能得到自己想要的东西。

一些人认为数据库是个例外,是一种特殊情况,即能够忽略那种驱动力,该驱动力无处不在,并促使我们更频繁地做出改变和对实际需求进行反应。没有更客气的方式来表达这个意思:那些人错了。数据库也不例外。当然,数据库开发者或许可以躲在海湾里将原来的开发领域保留得比其他产品开发领域更长一点,但是并不能阻止潮汐。在未来的几年或几十年里,快速做出变化的压力将变为压倒性的,并且坦率地说,与能适应该趋势的人相比,那些阻止这种趋势的人最终将被降级为不那么重要的角色。

1.1.2 若没有TDD敏捷就没有成效

试图得到快速的工作交付仅存在一个问题:变化是件危险的事情。如果你正在做交付价值的事情,那么对这件事所做的变更必然会危及价值的持续交付。如果你的产品停止交付价值,那么你就会开始失去与客户的良好关系。如果任由上述腐化持续足够长的时间,你就会开始失去客户。

除了那些把股票借给对冲基金公司来做“放空”操作的托管代理机构,以及做类似事情的组织之外,没有人想要失去客户1。所以,即使变化发生得非常频繁,保护价值的机制也必须落实到位,这样的机制才允许我们能够很快地做出改变。

上述机制就是测试驱动开发。测试驱动开发提供了多种优势,但对于本书所讨论的内容来说,其主要优势是用自动测试为软件组件提供充足和有意义的保护。部署到位的测试一方面能够在破坏了某些代码时立即给你反馈,另一方面也能防止你把某些已处于被破坏状态的代码作为产品发布出来,这两方面的优势缺一不可。

除了上述测试驱动开发最关键的好处之外,还有许多其他好处被很多人奉为 TDD 的“主要的”好处,包括加强软件设计分析或者戏剧性地减少过度构建。上述好处非常重要,本书将讨论这些好处,但是它们不会让你的开发工作做得很快,它们仅仅是帮你把工作做得快一点而已。

1.1.3 在数据库领域运用TDD是个挑战

本书之所以存在,是因为 TDD 非常难以在数据库开发中得到运用,特别是难以用一种能够让开发者快速地对变更进行开发、验证和发布的方式来运用。

这种困难很大程度上源于开发人员最初构建数据库的方式。在许多组织中,数据库是远古遗迹。一些特定的数据库实例非常重要,且其重要性已经让设计本身黯然失色。

我见过许多这样的案例,开发者只基于一些极其重要的实例来考虑数据库的设计而不顾其他。也就是说,他们只考虑设计“这个”开发数据库、“这个”测试数据库和“这个”生产数据库(production database),并且他们主要关心如何将变化从一个数据库传播到另一个数据库。为了使用测试驱动开发进行数据库设计,这种思考方式必须做出180°的大转变。

本书接下来的各个章节将解释如何能做到这一点。

1 在美国,一些大型投资基金机构购买股票后,一般将其托管在由一些大的银行或券商组成的托管代理机构手里。另外,一些对冲基金公司可以从上述托管代理机构手中借到股票来进行“放空”操作,为此对冲基金公司需要向托管代理机构支付利息。对于这些托管代理机构,一方面其客户不会知道它们可以把卖家已经卖出的股票再借给对冲基金公司来做“放空”操作,另一方面其手中持有的上述这些用于做“放空”的股票十分稀缺,所以这些托管代理机构不用担心失去客户。—译者注
本文仅用于学习和交流目的,不代表异步社区观点。非商业转载请注明作译者、出处,并保留本文的原始链接。

网友评论

登录后评论
0/500
评论
异步社区
+ 关注