演示数据即代码

自动化助力协作。

托马斯 A. 利蒙切利

工程师经常被要求出于各种原因生成演示数据。这似乎是一项一次性任务，可以手动完成并被遗忘。然而，自动化这个过程有很多好处，并支持迭代、协作和未来更新的必然需求。当数据被视为代码时，您可以利用现代软件工程实践中的技术。

多年前，我曾在一家公司工作，该公司需要制作其软件的演示版本。演示本质上是预装了虚构数据的公司软件。销售人员会按照脚本向客户演示产品的功能。脚本内容包括发现各种问题，并以只有该产品才能提供的轻松方式解决这些问题。

市场营销部门会创建脚本，而工程部门会创建支持故事情节的数据集。

在演示中使用实时的客户数据是不可行的，因为那会侵犯隐私。即便如此，也没有任何一个客户数据集能够支持整个演示脚本。

这个项目有很多危险信号。工程师们被期望“在业余时间”完成这项工作。这误解并贬低了工程工作。当非技术管理人员不理解某些事情时，他们通常会认为这很容易做到，因此显然不应该花费很长时间。

更令人担忧的是，这种“业余时间”理论得到了一个不正确的假设的支持，即该项目是一次性的。也就是说，数据将被生成一次，并且第一次尝试就完美无缺；然后工程师们可以对此事撒手不管，回到他们日常安排的工作中。

这个假设本意是赞扬工程师，但是，“哦，拜托，这只需要一个下午！”并不是良好项目管理的原则。

我不知道您是怎么想的，但我从未为市场营销部门制作过任何东西，而没有被要求至少进行一次修订或调整。这是两组人之间的创造性协作。任何这样的项目都需要多次迭代和实验，才能获得良好或足够好的结果。

市场营销部门认为，通过保持需求模糊不清，工程师们可以更容易地在第一次尝试时就生成完美的数据集。这与现实恰恰相反。通过这样做，市场营销部门在不知不觉中要求采用瀑布式方法，认为一次性完成的方法会减少工程师的时间浪费。但现实情况是，大爆炸式、一次性完成的方法总是会失败。

被指派负责该项目的主要工程师很快发现了这些危险信号，并意识到为了使该项目取得成功，他需要一种方法，该方法既能允许现在的迭代，又能提供在几个月后软件 2.0 版本需要更新演示时有效更新项目的功能。

为了解决这个问题，这位工程师创建了一个系统，用于从其他数据生成演示数据。它将根据需要以编程方式修改数据。因此，未来的更新可以简单地从头开始重新生成数据，并在数据上执行略有不同的操作。

他创建的系统基本上是一种微型语言，用于以可重复的方式提取和修改数据。其中一些功能包括

• 从各种来源导入数据的能力。

• 插入预定义的（静态）数据示例的能力。

• 从一个数据库中提取数据的功能，可以进行或不进行剪切或过滤。

• 通过调用函数 f 合成虚假数据。

• 使用函数 g 转换数据。

• 各种匿名化方法。

数据是通过一个“程序”生成的，该程序看起来像这样

# 销售人员需要能够展示“问题 X”。 # 我们在 customer1 的数据集中找到了这个数据，但是我们 # 只需要前 200 行 AnonymizeAndInject("customer1.data", 200) # 注意：使用 customer1 数据的批准记录在工单 #12345 中。 # 注意：匿名化技术已在工单 #45678 中签字确认。 # 接下来销售人员将演示的是当 # 问题 X 解决后会是什么样子。 # 函数 X 生成看起来像那样的数据。 # 它基于市场营销部门提供的 dataset2.data。 GenerateAndInject(X, "dataset2.data") # 有一个要求，即至少有一个“问题 Y” # 将在数据中看到。我们手动创建了该数据。 Include("problem-y.csv")

与其说这是一种新语言，不如说它是一个可重用函数库。新功能是按需添加的，根据需要添加函数。

由于演示数据是以这种方式生成的，因此很容易重新生成和迭代。例如，市场营销经理会来找我们说：“多来点牛铃！”我们可以添加一个语句，例如 GenerateAndInject(cowbell)。第二天我们会收到通知，“牛铃看起来太蓝了。可以改成红色吗？”然后我们会添加代码将其变成红色。重新运行代码，我们就准备好展示下一次迭代了。

匿名化尤其难以在第一次尝试时就做对。人们非常不擅长匿名化数据。算法有时也好不到哪里去。需要多次尝试才能将其做好。一旦它被认为是“足够好”了，源数据总是会发生变化。拥有自动化的流程是一种福音。

请注意，示例代码包含注释，以记录数据的来源和各种批准。如果出现问题、投诉、审计或法律问题，我们会非常高兴这些都被记录下来了。

这比手动编辑数据好太多了。

几个月后，当需要更新演示时，这种方法真的得到了回报。软件 2.0 版本即将发布，市场营销经理希望进行三项更改。首先，他们希望数据更加新颖。这不成问题。我们添加了一个函数，将数据中的所有日期向前移动了三个月，从而提供了更新鲜的外观。其次，脚本现在包含了一个故事情节，以展示一项新功能，我们需要提供数据来实现这一点。这也很容易，因为我们可以生成适当的数据并将其集成到数据库中。最后，新的演示需要使用最新版本的软件，该软件具有不同的数据库架构。代码已根据需要进行了更新。

哦，它仍然需要完成旧演示所做的所有事情。

如果演示数据是手工制作的，那么这些更改几乎是不可能的。我们将不得不重现每一个手动更改和更新。谁会记得每一个细微的更改呢？

幸运的是，我们不必记住。代码告诉我们我们做出的每一个决定。那么，为了更好地显示而将一个数据值减半的那次呢？没有人需要记住这一点。代码中甚至有一条注释解释了我们为什么要这样做。我们将标记为“Boise”的每个数据点都更改为“Paris”的那次呢？也没有人需要记住。见鬼，Makefile 编码了原始客户数据是如何提取和清理的。

我们能够轻松地进行所要求的更改。即使数据库架构的更改也不是什么大问题，因为生成器使用了与产品相同的库。它只是奏效了。

是的，我们确实手动检查了销售脚本，并确保我们没有破坏演示期间讲述的任何故事。我们本可以实施单元测试来确保我们没有破坏或丢失它们，但在这种情况下，手动测试是可以接受的。

创建这种微型语言花费的时间比最初“只需要一个下午”的估计时间还要长。在外人看来，这可能像是无缘无故的拖延。当时有压力要“尽快完成”，而不是投资于构建可重用的框架。然而，通过抵制这种压力，我们能够快速响应变更请求，按时交付最终演示，并在未来节省时间。

这种方法的另一个好处是它分散了工作。自动化实现了委托。小的更改可以由任何人完成；因此，主要工程师不是更新和修订的单点故障。初级工程师可以通过参与来积累经验。

每当您需要制作合成数据集时，我都强烈推荐这种技术。这通常是销售演示、开发人员测试数据、功能测试数据、负载测试数据以及许多其他情况所需要的。

用于制作此类系统的工具比过去好得多。这里描述的项目发生在多年前，当时可用的工具是 Perl、awk 和 sed。现代工具使这变得容易得多。Python 和 Ruby 可以轻松创建微型语言。R 有许多专门用于导入、清理和操作数据的库。通过将代码和其他源材料存储在诸如 Git 之类的版本控制系统中，您可以获得更改历史记录和通过 PR（拉取请求）进行协作的好处。现代 CI/CD（持续集成/持续交付）系统可用于提供始终新鲜且相关的数据。

理想情况下，演示数据应该成为发布周期的一部分，而不是事后才考虑的事情。功能请求应包括销售叙述和支持性示例数据。功能和相应的演示元素应同时开发并在同一时间交付。

结论

对演示数据集的随意请求可能看起来像是一次性事件，不需要自动化，但现实情况是，这是一个协作过程，需要多次迭代和实验。无疑会有大大小小的修订请求，需要匹配不断变化的软件，并支持新的和修订的演示故事。所有这些都使自动化该过程变得有价值。现代脚本语言使创建充当微型语言的临时函数变得容易。可重复的流程有助于协作，实现委托，并在现在和将来节省时间。

致谢

感谢 George Reilly (Stripe) 和许多匿名审稿人的有益建议。

数据草图
近似方法通常更快更有效。
Graham Cormode
https://queue.org.cn/detail.cfm?id=3104030

自动化软件故障报告
我们只能修复我们知道的那些错误。
Brendan Murphy
https://queue.org.cn/detail.cfm?id=1036498

顺势而为
工作流系统可以提供超越自动化业务流程的价值。
Peter de Jong
https://queue.org.cn/detail.cfm?id=1122686

托马斯 A. 利蒙切利 是 Stack Overflow Inc. 在纽约市的 SRE 经理。他的著作包括 系统和网络管理实践 (http://the-sysadmin-book.com)、云系统管理实践 (http://the-cloud-book.com) 和 系统管理员的时间管理 (http://shop.oreilly.com/product/9780596007836.do)。他的博客是 EverythingSysadmin.com，推特是 @YesThatTom。他拥有德鲁大学计算机科学学士学位。

最初发表于 Queue vol. 17, no. 3—
在数字图书馆中评论这篇文章

更多相关文章

João Varajão, António Trigo - 评估 IT 项目的成功：感知与现实
这项研究通过提供对 IT 项目成功的新见解，对实践、研究和教育具有重大意义。它通过报告项目成功（而不仅仅是项目管理成功）扩展了项目管理知识体系，该项目成功基于几个客观标准，例如项目后期阶段客户对可交付成果的使用、客户对项目相关支持/维护服务的聘用、客户对新项目的签约以及客户向潜在客户推荐供应商。研究人员可以找到一组标准，他们可以在研究和报告 IT 项目的成功时使用这些标准，从而扩展当前对评估的看法，并有助于得出更准确的结论。

Abi Noda, Margaret-Anne Storey, Nicole Forsgren, Michaela Greiler - DevEx：真正驱动生产力的因素
开发者体验侧重于开发者的生活体验以及他们在日常工作中遇到的摩擦点。除了提高生产力外，DevEx 还通过提高效率、产品质量和员工保留率来推动业务绩效。本文为理解 DevEx 提供了一个实用的框架，并提出了一个测量框架，该框架将来自开发人员的反馈与他们与之交互的工程系统的数据相结合。这两个框架为领导者提供了清晰、可操作的见解，了解需要衡量什么以及重点关注哪里，以便提高开发人员的生产力。

Jenna Butler, Catherine Yeh - 设身处地为他人着想
新冠疫情在许多方面改变了人们的工作方式，但许多结果本质上是自相矛盾的。对一个人有效的方法可能对另一个人无效（甚至对同一个人第二天也无效），我们尚未弄清楚如何准确预测什么对每个人都有效。正如您在本文描述的综合角色中所看到的，有些人与世隔绝和孤独作斗争，很难与他们的团队进行社交联系，或者发现混合工作模式和远程团队的时间压力令人难以承受。另一些人则喜欢这种新发现的工作方式，享受更多与家人共处的时间、白天锻炼的更大灵活性、更好的工作/生活平衡以及更强烈的为世界做出贡献的愿望。

Bridget Kromhout - 容器不会修复你破碎的文化（以及其他残酷的真相）
我们经常关注技术反模式，而忽略了我们社会结构内部的类似问题。剧透警告：许多看似技术性的难题的解决方案可以通过检查我们与他人的互动来找到。让我们来谈谈在与那些被称为人类的讨厌生物一起工作时，您需要了解的五件事。