停止追赶最新的 RPA 趋势

作者 | Anupam Krishnamurthy

译者 | Phoenix

策划 | 蔡芳芳

本文最初发布于 anupam.de 博客，由 InfoQ 中文站翻译并分享。

我做了 4 年的 RPA 开发者——2017 至 2021 年。在 2019 年底，我做了一个重要的决定，使我入选为 UiPath's 2021 年 62 位 MVP 之一。这个决定就是停止追赶最新的 RPA 趋势，转而专注于掌握传统的软件开发。

当然，一开始不是这样的，在我作为 RPA 开发人员的头两年里，我坚持只使用本地 RPA 工作流来实现流程自动化。我不是 IT 背景出身，所以我认为传统的编程和脚本不适合我，我将 RPA 视为一种与基于文本编程不同的编程范式，并拒绝偏离它。同时，我震撼于 RPA 的强大和上手之快速，这也让我看不到它的局限性。

RPA 市场规模每年都在呈数量级增长，现在的 RPA 平台比 2017 年强大得多。这使得作为一名 RPA 开发者，更倾向于“专攻”RPA，而不是脱离它的边界。这里列出 3 个理由来简述为什么这种想法是错误的。

为什么只局限于“RPA”是错误的

基于 GUI 的自动化终归是一种妥协

任何软件过程的自动化，本质上都需要使用一系列命令将数据从一个地方移动到另一个地方。过去几十年里，程序员已经完善了命名贴切的命令行执行这些操作的方法。然而，为了将计算机的使用范围扩展到日常用户，我们创建了一个更直观的用户界面——有鼠标指针、按钮、文本框、触摸屏等等。

进入图形用户界面，我们现在太习惯使用 GUI 了，以至于我们认为它们是理所当然的。而作为程序员，我们需要提醒自己，每次使用 GUI 时，计算机都会执行数字体操来满足我们的需求。每次你点击屏幕上的一个按钮，计算机都会投入巨大的精力把这个手势转换成一个命令。它必须：

• 在屏幕上正确呈现按钮

• 跟踪鼠标指针的位置

• 注册按钮的点击

• 执行相应的命令

或者，用一行程序代码发出命令，就像用计算机的母语说话一样，高效而健壮，信息损失最小。

大多数原生 RPA 自动化都是基于 GUI 的，花点时间让大家了解一下，基于 GUI 的自动化，包括指示机器人通过 UI 与另一个程序通信，这类似于强迫两个相同母语的人用猜字谜的方式来进行交流。基于 GUI 的自动化终归是一种妥协，因为在底层总是有更有效的方法来执行相同的任务，这引出了我第二个理由。

原生 RPA 流程在生产环境中很脆弱

在很长一段时间里，我没有意识到基于 GUI 的自动化是多么的脆弱，因为我在自己的计算机上实现了每个过程的自动化，所以我无法预料在生产环境中运行它会有什么不同。当我转到一个在生产环境中维护 RPA 流程的团队时，一切都变了。我的团队超过 80% 的时间都花在了修复损坏的流程上，这使我们几乎没有时间自动化新的流程。这种脆弱性主要源于生产环境总是与我们开发自动化的笔记本电脑和测试系统不同。一个由 100 个连续步骤组成的自动化过程的“强度”和它最弱的步骤一样，只需对 GUI 进行最小的更改就可以破坏整个过程。

作为一名 RPA 开发人员，你自己可能也经常遇到这种情况。我还没有看到过一个 RPA 过程，在生产环境第一次就能够完美地执行。当然，人们可能会认为这种情况正在改变，随着智能选择器和计算机视觉等 RPA 技术的进步，RPA 流程现在可以更灵活地应对 GUI 中的变化。这又引出了我第三个原因。

商品化

在前 RPA 时代，要自动化一个 Web 应用程序，你需要检查浏览器上的网页，筛选复杂的 HTML 和 CSS 来找到一个可靠的选择器；而使用 RPA，开发人员只需单击元素即可检索其选择器；在下一次迭代中，我们有了支持正则表达式并包含一些模糊逻辑的智能选择器；再下一个飞跃是计算机视觉——RPA 软件现在可以像人类用户一样，查看屏幕，识别文本字段、单选按钮和复选框。

随着 RPA 平台的快速成熟，RPA 工作也随之商品化。RPA 平台实现自动化越容易，所需要的员工技能水平就越低，这种趋势类似于餐饮业的工业化，在过去，你需要雇佣一个厨师来经营一家餐厅；然而，工业化让你有可能和一个中学辍学生经营一家快餐店。是的，厨师在当今世界仍然很有价值，但这是因为他们磨砺技艺，不断地改造自己。

解决办法

在我 RPA 职业生涯的早期，我的错误在于没有认识到这些因素，下面是我希望自己早点采取的 3 条措施。

像软件工程师一样思考

2019 年 12 月，我读了 Bob C. Martin 的《代码整洁之道》，它改变了我看待计算机编程的方式，让我能够从一个经验丰富的软件开发人员的角度来检查一段代码。我注意到一个人不仅需要解决眼前的问题，还需要为下游可能出现的二阶和三阶问题进行设计。我还意识到，在本质上，RPA 开发与优秀的传统软件开发并没有太大的区别。此外，比 RPA 早几十年的软件工程技术已经解决了 RPA 开发人员刚刚意识到的大多数问题。

除了阅读《代码整洁之道》和《笨办法学 Python 3》等书籍外，还有助于与软件工程师讨论他们如何实现自动化，我经常会向我的开发朋友解释我正在自动化的场景，并问他将如何处理。这帮助我发现了基于 GUI 的自动化的绝佳替代方案，这也引出了我的第二个建议。

学习使用传统编程语言实现自动化

所有 RPA 平台都构建在传统编程框架之上，大多数 RPA 自动化是在. NET 平台上完成的，所以在底层都使用了 C# 或 Visual Basic。从简单的工作流开始，尝试用. NET 语言绕过 RPA 平台，通过这种方式，你可以更深入地理解 RPA 软件的工作原理。此外，你还会意识到，在某些情况下，几行代码就可以实现与复杂的 RPA 工作流（跨越你监视器的两个长度）相同的最终结果。

获得更多经验的另一种方法是为你最常用的 RPA 平台创建自定义活动。这段经历会让你对它内部运作有宝贵的洞察。

我推荐一个极好的学习 Python 自动化的资源是“Automate the Boring Stuff with Python”。

集成 RPA 与传统软件

一旦你开始像软件工程师一样思考，并向你的工具包中添加一些编程技巧，你就可以构建优雅的流程，将 RPA 平台的集中编排与传统编程的健壮性和效率相结合。使用.NET，你可以在大多数 Windows 应用程序上自动化任务，你可以映射网络驱动器、集成 DLL，创建自定义活动，所有这些都将加速你的 RPA 代码。要与 SAP 集成，请参阅 Stefan Schnell 的 SAP Scription Tracker （https://tracker.stschnell.de/）及其神奇的工作原理，你可以通过构建 CI-CD 管道来自动化 RPA 部署。最后一个集成是我最感兴趣的场景，将继续成为我对 RPA 社区最有价值的贡献。

小    结

我上面写的一些东西可能会让人难以接受，RPA 供应商和业内人士不太可能提出这样的观点，而我自己也是在从 RPA 职业生涯中走出后，以全新的眼光回顾这个行业，才能清楚地看到这一点。

此外，我的建议是回到传统的软件开发，而不是紧跟最新的 RPA 趋势，这可能会显得过时。但是，如果你打算以长远的角度看待作为开发者的职业生涯，就需要掌握那些经受住时间考验的传统技能。

真希望我能早点意识到这一点。

原文链接

https://anupam.de/projects/descriptify/articles/articles/BiggestMistakeasRPADeveloper.html

你也「在看」吗？👇