發表日期 3/31/2022, 2:06:22 PM
作者 | 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