一名合格的UiPath開發人員究竟須要具有什麼核心技能？業務梳理？溝通技巧？VB.net嗎？VBA嗎？Python？仍是SQL？出於多種緣由，關於這一點老是衆說紛紜，莫衷一是。儘管這些技術都算沾邊，但我始終以爲並無觸及RPA或者UiPath的核心。
那麼我就反過來想，究竟缺乏了哪一點，RPA就再也不可以稱之爲RPA？
一上來就直面這個問題，實際上是有些困難的。因而我便進一步問本身，RPA究竟是什麼？
我相信許多同行跟我同樣，常常被問到——所謂的RPA，跟按鍵精靈到底有啥區別？我努力試圖向人們解釋RPA比按鍵精靈更高大上，但每每人們的表情依然困惑。一我的問，可能只是個疑問，一萬我的問，那一定有什麼道理。爲此我左思右想，突然以爲以往試圖強行將它與按鍵精靈區分開，彷佛是個錯誤的方向。這個東西，本質上跟按鍵精靈並無什麼不一樣，都是圖形界面的自動化技術。至少在單機環境下，按鍵精靈和各類RPA工具理應可以實現一樣的功能和效果。這麼一想，就豁然開朗起來。
那麼既然RPA是圖形界面的自動化技術，這一類技術的核心是什麼？
固然是找到正確的界面元素，並與其進行預期的交互。因此說，搞明白在UiPath中如何準確地定位界面元素，是UiPath開發的首要技術要求。
那麼在UiPath中定位元素，有哪些關鍵知識點呢？
我認爲有如下幾點。
完整選擇器
部分選擇器
模糊選擇器
絕對定位
相對定位
動態定位
其中動態定位技術最複雜，涉及一些相關的Activities，包括但不限於：
Anchor Base
Context Aware Anchor
Element Scope
Find Children
Find Relative Element
Get Ancestor
Indicate On Screen
Pick
Try ... Catch ...
Switch
Throw
Rethrow
Get Position
等等。如何靈活運用以上知識進行準確的元素定位，纔是UiPath的核心技術。而且，以上說起的知識點也都是UiPath的難點。UiPath玩過好幾年但仍是沒有徹底搞懂上述知識的開發人員，我見過很多。新手更是常常在定位界面元素的問題上翻車。可見吃透定位技術並不容易。據我所知這方面的系統學習資料並很少，官方教程也只作掃盲然而並不深刻，只能全憑各人的鑽研和經驗積累，因此能夠用來考察UiPath開發人員的功力深淺。
我以爲將它視爲UiPath開發人員技術合格與否的第一道分水嶺都不爲過。
核心定義的後半句話是，進行預期交互的能力。預期交互是指什麼呢？其實說白了，就是設計和實現邏輯分支的能力。
有的人可能會以爲，實現邏輯分支有什麼難的？不就寫個if/Else，True/False嘛？會這麼想雖然算有些理解，但缺乏實踐支撐。
我知道有很多人在設計流程的時候，是線性的思惟，流程圖是一條直線一二三四走下來，開發的時候也經常喜歡用Sequence一條寫到底。這樣遇到小的邏輯分支還能修修改改，遇到大的邏輯分支就完蛋了，徹底改不動。一個典型的例子就是登陸流程的設計，每每一登陸就了事，歷來不想密碼錯了流程怎麼走，密碼過時了流程怎麼走，登陸成功仍是失敗也不確認，遇到任何異常就簡單粗暴地重試三次了事，最終致使帳戶被鎖定，纔回頭想辦法返工重作。登陸的例子還算簡單明瞭，有些場景邏輯分支實現起來至關複雜，須要對業務異常和技術異常全盤考慮儘可能處理，還要兼顧用戶需求，就很棘手。特別是異常流程要怎麼走，應該作到什麼，能作到什麼，什麼動做作不了，這些事內心有沒有數，也是應該考察的重點之一。
以100分制來打比方的話，定位技術能夠用來判斷UiPath開發人員達到60分沒有，而按預期進行交互的能力則能夠用來評判是否達到80分。
另外，因爲目前大多數RPA客戶還處於小打小鬧的嚐鮮狀態，許多RPA項目只是作Front-Office Robot，即前端的，助手形的機器人。這種類型的機器人設計上有一個特色是自動化流程有可能與用戶當前的操做同時進行。所以，如何儘可能避免影響用戶操做，也是一個雖然不大但蠻重要的考察點。
與傳統IT開發技術不一樣，準確和穩定是RPA的首要要求，性能雖然也蠻重要但其實不多優先考慮。
