“任何你做两次以上的事情都必须自动化。” 这听起来像是一句很棒的引述。不过要小心。自动化比自动化过程成本更高。
这是我在下面分享的一个真实案例。
真实案例
我们网站开发初期有一段代码是比较重复的。它正在创建一个 SQL 表和一组函数，如插入、更新、删除等，并连接到该表的数据模型。
每次创建表时，都必须经历创建和复制表内容及其 SQL 命令功能。
识别重复过程
随着我们开始开发，越来越多的请求要求存储新数据，因此可能会有更多新表和 SQL 需要编程。
这太可怕了。
自动化——并不像我们想象的那么难
因此，我们不是手动复制和修改它，而是创建一个脚本，以最少的输入生成所有样板代码。它运作良好，也被纳入我们的 CI 流程。
我们现在没有复制代码，而是有一些固定数据可以提供给自动化脚本，这将生成所有需要的 Golang 代码供我们的网站应用程序使用。
哦，我们需要一些修改
在创建了大约四到五个数据表之后，创建更多表的需求就停止了，因为更多的功能集中在增强应用程序的功能上，而不是向其中插入更多数据。
后来，随着我们的进一步推进，我们意识到我们需要修改一些 SQL 函数。更改很小，但仅适用于某些表。
为该自定义更改修改自动化脚本既棘手又昂贵。该脚本是用另一种语言编写的，要了解它的改进之处并不容易。
由于我们需要快速投入生产，我们的想法是，让我们通过手动修改生成的代码来破解它。
像往常一样，没有人有时间回去偿还技术债务。相反，需要对另一张表进行另一项更改。同样的事情发生了——更多手动修改黑科技。
废弃的生成代码没有所有权
就生成代码的状态而言，它是通过内部的一些骇人听闻的修改生成的，没有人愿意声称所有权并对其进行处理。
代码很快就会变得陈旧，甚至更难理解它在做什么。如果需要任何进一步的更改，则会在应用程序代码中添加更多黑科技来规避它。
为了改善这种情况，我们不能再进行增量改进来演进代码。相反，需要对内部内容进行重大改造。这都是没有人想要拥有它的结果。
当我们认为一旦我们设置了自动化，它就会让我们从工作中解脱出来，我们不再需要担心它时，它的垮台就开始了。这是一个谬误，导致了如此悲惨的结果。
自动化比看起来更昂贵
当我们第一次想到自动化时，我们首先想到的是制作它们的复杂性，如下图所示：
我们都知道这一点。但这并不是成本自动化要求的全部。让我们看看其他的：
非常规成本
我们通常在软件开发中使用行业提供的特定常规开发流程。它们都得到了很好的支持并且易于使用。
然而，为了实现一些特定于我们需求的自动化，我们必须做一些不同的事情，例如，工具、流程、编程语言等。
我们下面的例子可以解释我的意思。
通常对于网站开发，我们只需要Go语言。我们需要一个精通 Go 开发的团队。
当我们添加上面的自动化时，我们使用了一个与 Go 开发流程不同寻常的脚本。这意味着我们的团队中需要有人也熟悉 Python 脚本。此外，我们需要确保我们按照 Python 的最佳实践正确地进行操作并继续更新。
Python 脚本的入口是一些非常规的 XML 标记。当新人加入该组时，他们将需要了解特定的 XML 标记，这不是行业标准。对于新员工来说，这不是一种非常有激励作用的增值体验。我们不可能也提前雇用具有此类知识的任何人。
当我们创建自动化时，需要考虑这些成本。为了尽可能减少非常规流量，我们应该尝试以下方法：
限制我们必须用来自动化它的变体。它具有的变体越多，它产生的非常规成本就越高。
尽量保持更好的社区支持的工业标准。如果我们遇到问题，我们知道我们并非孤军奋战。这就是为什么大型组织更愿意为工具付费而不是使用免费工具的原因之一。它为“支持”提供了更好的保证。
维修费用
没有什么是免费的。即使在我们将流程自动化之后，它也不是免费的。我们将全部成本从手动工作转移到创建和维护自动化的成本。
很多时间被忽略的是自动化的维护成本。
假设自动化代码不需要更改和改进，仍然需要不时升级工具或库。这些都是创建自动化时不存在的未来开销。
它们不是免费的，在我们考虑自动化时需要考虑在内。
一个非常简单的例子。
在 CI 流程之前，公司有一个管理整个流程的软件部门，有许多手动代码检查和交付流程。
理想情况下，我们可以改进和自动化检查代码和运输，希望不会产生任何其他成本。但我们知道它不那么可持续，因为 CI 自动化知识需要不同领域的专业知识来改进它。
因此，为了实现可持续发展，大多数公司创建了一个不同的团队 Dev Ops 来维持 CI 流程。这些是创建的自动化的“维护成本”。因此，它不是免费的。
有了它，我们就知道如何将总自动化成本等同于以下公式：
自动化成本 = 创建成本 + 维护成本
假设输出相同（数量和质量），那么我们认为考虑自动化的简单数学是确保
（自动化创建 + 维护成本）<（手动工作成本）
这种简单的匹配是为了确保我们至少应该确保我们的总自动化成本不应该高于人工成本。
但这还不是全部……
丢失上下文成本
我们认为维护成本越低越好。虽然这是事实，但我们还需要考虑另一个重要因素。
一旦我们通过了自动化成本（创建和维护）的门槛，自动化似乎是值得追求的。
但问题是，维护成本应该低到什么程度呢？这是一个包含三个选项的示例：
从简单的成本角度来看，选项 1 似乎是最好的。如果我们不需要更改为自动化，为什么要有专门的开发人员呢？
但如果我们不小心，我们将陷入一个潜在的更大的未来问题。让我举例说明。
以我们上面的案例为例。
假设我们的自动化做得很好，我们可以继续重复使用它而不做任何改变。创建这种自动化的投资回报率是最值得的！
但有一个警告。由于其效率，多年来未对其或其输出进行任何更改。每个人都可以舒适地使用它们。
一段时间后，创建自动化的人不再在团队中。没有人觉得这是个问题，因为它仍然有效。创造它的人甚至都不记得它了，因为它是“几个世纪”前创造的。
但就像任何软件一样，没有什么是持久的。有一天，有些事情需要改变。这个自动化代码对整个团队来说就像一个黑匣子。我们无法对其进行增量演化。唯一的选择是从头开始重新创建所有内容，而无需参考过去内部所做的事情。
自动化越大，重建它的成本就越高。丢失上下文的成本没有警告标志。这是一颗定时炸弹，不是如果，而是如果我们不注意它就会在什么时候爆炸。
为了缓解这个问题，我们需要考虑到如果我们的维护成本太低而导致的“丢失上下文”成本。
以下是陷阱：
我们不应该有太高的自动化成本（创建+维护），以至于最终成本高于手动工作成本
我们不应该偷工减料来降低自动化成本（创建 + 维护），否则我们可能会失去上下文或在未来控制它的发展。
因此，如果我绘制相同的图表并考虑丢失自动化上下文的风险（低于 A 点的任何内容）。
现在我们可以清楚地看到，A 点和 B 点之间的任何选项都是值得自动化的最佳点。理想情况下，我们希望尽可能接近 A。
得出结论：
选项 3 已被淘汰，因为它比手动操作成本更高。
尽管选项 1 的成本较低，但它具有不值得追求的未来风险。
相反，选项 2 虽然成本更高，但如果这种自动化是在对业务至关重要的软件产品上进行的，则值得采用。
自动化就像任何软件开发一样
为我们的软件开发创建自动化是软件开发的另一部分。创建它的初始成本只是冰山一角。如下所示，我们需要考虑保留它的后续成本。
我们软件的自动化部分需要不断改变和改进。如果它保持不变且无人看管，它很快就会陈旧并成为一个隐藏的、未知的黑匣子。我们要么继续支付费用以维护它，要么稍后支付罚款，这可能代价高昂。
维护它的一个简单秘诀就是让某人拥有并维护它。它很简单但经常被忽视，有良好拥有的代码是维护良好的代码。
简而言之，“任何你做超过两次的事情都必须自动化”不是一句好话。
相反，这可能是一个更好的引用，“任何你自动化的东西都必须维护。”
如果你喜欢我的文章，点赞，关注，转发！
