來源：AI前線

作者：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

未來智能實驗室的主要工作包括：建立AI智能系統智商評測體系，開展世界人工智能智商評測；開展互聯網（城市）大腦研究計劃，構建互聯網（城市）大腦技術和企業圖譜，為提升企業，行業與城市的智能水平服務。每日推薦范圍未來科技發展趨勢的學習型文章。目前線上平臺已收藏上千篇精華前沿科技文章和報告。

??如果您對實驗室的研究感興趣，歡迎加入未來智能實驗室線上平臺。掃描以下二維碼或點擊本文左下角“閱讀原文”

總結

以上是生活随笔為你收集整理的停止追赶最新的 RPA 趋势的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。