在 "无责 DevOps 中的失败是一种特性" 中，我讨论了通过征求反馈意见来交付质量的过程中，失败所起到的核心作用。 这是敏捷 DevOps 团队赖以引导他们并驱动开发的失败。 测试驱动开发 (TDD) 是任何敏捷 DevOps 价值流交付的必要条件。只有与可测量的测试相结合，以失败为中心的 TDD 方法才能发挥作用。
TDD 方法是基于自然规律建模的，以及自然如何在进化游戏中产生赢家和输家。
自然选择
1859 年，查尔斯·达尔文在他的著作物种起源中提出了进化论。 达尔文的论点是，自然变异是由个体生物的自发突变和环境压力共同造成的。 这些压力淘汰了适应性较差的生物，同时青睐其他更适应的生物。 每个活着的生物都会突变它的染色体，这些自发突变会传递给下一代（后代）。 然后，在新出现的可变性在自然选择（由于环境条件的可变性而存在的环境压力）下进行测试。
此简化图说明了适应环境条件的过程。
图 1. 不同的环境压力导致由自然选择决定的不同结果。图片截图来自 Richard Dawkins 的视频。
此图显示了一群鱼在其自然栖息地中。 栖息地各不相同（海底或河床底部较深或较浅的砾石），每条鱼也各不相同（较深或较浅的身体图案和颜色）。
它还显示了两种情况（即，环境压力的两种变化）
- 捕食者的存在
- 捕食者不存在
在第一种情况下，更容易在砾石阴影下被发现的鱼类更有可能被捕食者杀死。 当砾石较暗时，较浅的鱼类种群会被稀释。 反之亦然——当砾石的阴影较浅时，较深的鱼类种群会遭受稀释的情况。
在第二种情况下，鱼类足够放松以进行交配。 在没有捕食者和交配仪式的情况下，可以预期相反的结果：在背景中脱颖而出的鱼更有可能被选中进行交配，并将它们的特征传递给后代。
选择标准
在各种变数中进行选择时，该过程永远不是任意的、反复无常的、异想天开的或随机的。 决定性因素始终是可衡量的。 这个决定性因素通常被称为测试或目标。
一个简单的数学示例可以说明这个决策过程。 （仅在这种情况下，它不会由自然选择控制，而是由人工选择控制。）假设有人要求你构建一个小函数，该函数将采用一个正数并计算该数的平方根。 你会怎么做？
敏捷 DevOps 的方式是快速失败。 以谦虚的态度开始，一开始就承认你并不真正知道如何开发该函数。 在这一点上，你所知道的只是如何描述你想做什么。 用技术术语来说，你已准备好参与制作单元测试。
“单元测试”描述了你的具体期望。 它可以简单地表述为“给定数字 16，我希望平方根函数返回数字 4。” 你可能知道 16 的平方根是 4。但是，你不知道一些更大的数字（例如 533）的平方根。
至少，你已经制定了你的选择标准，你的测试或目标。
实现失败的测试
.NET Core 平台可以说明实现方式。 .NET 通常使用 xUnit.net 作为单元测试框架。 （要遵循编码示例，请安装 .NET Core 和 xUnit.net。）
打开命令行并创建一个文件夹，你将在其中实现平方根解决方案。 例如，键入
mkdir square_root然后键入
cd square_root为单元测试创建一个单独的文件夹
mkdir unit_tests进入 unit_tests 文件夹 (cd unit_tests) 并启动 xUnit 框架
dotnet new xunit现在，向上移动一个文件夹到 square_root 文件夹，并创建 app 文件夹
mkdir app
cd app创建 C# 代码所需的支架
dotnet new classlib现在打开你喜欢的编辑器并开始破解！
在你的代码编辑器中，导航到 unit_tests 文件夹并打开 UnitTest1.cs。
将 UnitTest1.cs 中的自动生成代码替换为
using System;
using Xunit;
using app;
namespace unit_tests{
public class UnitTest1{
Calculator calculator = new Calculator();
[Fact]
public void GivenPositiveNumberCalculateSquareRoot(){
var expected = 4;
var actual = calculator.CalculateSquareRoot(16);
Assert.Equal(expected, actual);
}
}
}此单元测试描述了变量 expected 应为 4 的期望。 下一行描述了 actual 值。 它建议通过向名为 calculator 的组件发送消息来计算 actual 值。 该组件被描述为能够通过接受数值来处理 CalculateSquareRoot 消息。 该组件尚未开发。 但这并不重要，因为这仅仅描述了期望。
最后，它描述了何时触发消息发送。 届时，它会断言 expected 值是否等于 actual 值。 如果是，则测试通过，目标达成。 如果 expected 值不等于 actual 值，则测试失败。
接下来，要实现名为 calculator 的组件，请在 app 文件夹中创建一个新文件并将其命名为 Calculator.cs。 要实现一个计算数字平方根的函数，请将以下代码添加到此新文件中
namespace app {
public class Calculator {
public double CalculateSquareRoot(double number) {
double bestGuess = number;
return bestGuess;
}
}
}在你测试此实现之前，你需要指示单元测试如何找到这个新组件 (Calculator)。 导航到 unit_tests 文件夹并打开 unit_tests.csproj 文件。 在 <ItemGroup> 代码块中添加以下行
<ProjectReference Include="../app/app.csproj" />保存 unit_test.csproj 文件。 现在你已准备好进行首次测试运行。
转到命令行并将 cd 进入 unit_tests 文件夹。 运行以下命令
dotnet test运行单元测试将产生以下输出
图 2. 单元测试运行失败后的 xUnit 输出。
正如你所看到的，单元测试失败了。 它期望向 calculator 组件发送数字 16 会导致数字 4 作为输出，但输出（actual 值）是数字 16。
恭喜！ 你已经创建了你的第一次失败。 你的单元测试提供了强烈、即时的反馈，敦促你修复失败。
修复失败
要修复失败，你必须改进 bestGuess。 现在，bestGuess 只是采用该函数接收的数字并返回它。 不够好。
但是你如何找到计算平方根值的方法？ 我有一个想法——看看大自然是如何解决问题的。
通过迭代来效仿大自然
从第一次（也是唯一一次）尝试中猜出正确的值非常困难（几乎是不可能的）。 你必须允许多次尝试猜测，以增加解决问题的机会。 允许多次尝试的一种方法是迭代。
要迭代，请将 bestGuess 值存储在 previousGuess 变量中，转换 bestGuess 值，并比较两个值之间的差异。 如果差异为 0，则你解决了问题。 否则，继续迭代。
这是生成任何正数平方根正确值的函数体
double bestGuess = number;
double previousGuess;
do {
previousGuess = bestGuess;
bestGuess = (previousGuess + (number/previousGuess))/2;
} while((bestGuess - previousGuess) != 0);
return bestGuess;此循环（迭代）将 bestGuess 值收敛到所需的解决方案。 现在你精心制作的单元测试通过了！
图 3. 单元测试成功，0 个测试失败。
迭代解决了问题
就像大自然的方法一样，在本练习中，迭代解决了问题。 增量方法与逐步改进相结合是获得满意解决方案的保证方法。 在这个游戏中，决定性因素是拥有一个可衡量的目标和测试。 一旦你拥有了它，你就可以继续迭代直到你击中目标。
现在是妙语！
好的，这是一个有趣的实验，但更有趣的发现来自于使用这个新铸造的解决方案。 到目前为止，你的起始 bestGuess 始终等于该函数接收的作为输入参数的数字。 如果你更改初始 bestGuess 会发生什么？
要测试这一点，你可以运行几个场景。 首先，观察逐步改进，因为迭代循环通过一系列猜测来尝试计算 25 的平方根
图 4. 迭代以计算 25 的平方根。
从 25 作为 bestGuess 开始，该函数需要八次迭代来计算 25 的平方根。但是，如果你对 bestGuess 进行了可笑的、荒谬的错误刺伤会发生什么？ 如果你从一个毫无头绪的第二个猜测开始，即一百万可能是 25 的平方根？ 在这种明显错误的情况下会发生什么？ 你的函数能够处理这种白痴行为吗？
看看马的嘴巴。 重新运行场景，这次从一百万开始作为 bestGuess
图 5. 通过以 1,000,000 作为初始 bestGuess 开始计算 25 的平方根时的逐步改进。
哇！ 从一个荒谬的数字开始，迭代次数仅增加了三倍（从八次迭代到 23 次迭代）。 远没有你直觉期望的那么剧烈的增加。
故事的寓意
Aha! 时刻是你意识到，迭代不仅保证可以解决问题，而且你对解决方案的搜索是以好的还是非常糟糕的初始猜测开始的都无关紧要。 无论你的初始理解多么错误，迭代过程，加上可衡量的测试/目标，都会让你走上正确的轨道并交付解决方案。 保证的。
图 4 和图 5 显示了一个陡峭而引人注目的消耗图。 从一个非常不正确的起点开始，迭代迅速消耗到一个绝对正确的解决方案。
简而言之，这种令人惊叹的方法是敏捷 DevOps 的本质。
回到一些高层观察
敏捷 DevOps 实践源于我们认识到，我们生活在一个从根本上基于不确定性、模糊性、不完整性和一定程度的混乱的世界中。从科学/哲学的角度来看，这些特性已被充分记录，并得到了以下理论的支持：海森堡不确定性原理（涵盖不确定性部分）、维特根斯坦的《逻辑哲学论》（模糊性部分）、哥德尔不完备性定理（不完整性方面）和热力学第二定律（持续的熵导致的混乱）。
简而言之，无论你多么努力，在试图解决任何问题时，你永远无法获得完整的信息。因此，放弃傲慢的姿态，采取更谦逊的方法来解决问题更有利。谦逊的回报是巨大的，它不仅会给你带来希望的解决方案，还会带来结构良好的解决方案的副产品。
结论
自然界不停地运作——它是一个持续的流动。自然界没有总体规划；一切都发生作为对先前发生的事情的回应。反馈循环非常紧密，并且表面上的进步/退步是零星的。在自然界的任何地方，你都会看到以一种或另一种形式逐步改进。
敏捷 DevOps 是工程模型逐渐成熟的一个非常有趣的结果。DevOps 基于这样的认识：你可用的信息始终是不完整的，所以你最好谨慎行事。获得一个可衡量的测试（例如，一个假设，一个可衡量的期望），谦逊地尝试满足它，很可能会失败，然后收集反馈，修复失败，并继续。除了同意每一步都必须有一个可衡量的假设/测试之外，没有其他计划。
在本系列文章的下一篇中，我将更仔细地研究变异测试如何提供价值驱动所需的反馈。
9 条评论