本文轉自：https://www.cnblogs.com/ybyebo/p/10086473.html
1. UI操作容易受到各種意外的干擾，因此應該縮短UI操作階段的總體時間。而為了縮短UI操作階段的總體時間，應該將UI操作盡量放在一起，將后台的各種操作盡量放在UI操作的前后。例如，現在有一個Assign和兩個Click需要執行，那么比較推薦的設計是Assign->Click->Click或者Click->Click->Assign，而不是Click->Assign->Click。集中的UI操作也會給人一種“機器人非常高效”的觀感，留下較良好的印象。
2. 為了確保“增加一倍的投入就必須相應提高一倍的效率”，流程的總體設計要盡量將問題轉化為事務式（Transactional）處理的模式。這是什么意思呢？假設現在有一份Excel表格記錄了賓客列表，機器人要讀取這份列表，為每位賓客生成一份Word請柬，然后以郵件形式發送出去。有一種流程設計思路是這樣的，機器人讀取賓客列表ABC后，為A生成請柬->為B生成請柬->為C生成請柬->向A發送郵件->向B發送郵件->向C發送郵件。這種流程設計模式雖然邏輯上沒有錯，但是多機器人共同協作時分割工作負載相對比較困難，很難確保“增加N倍數量的機器人可以以相應提高N倍的處理能力”。因此，應該盡可能的將流程設計為，機器人讀取賓客列表ABC后，為A生成請柬->向A發送郵件->為B生成請柬->向B發送郵件->為C生成請柬->向C發送郵件。可以看到在這個例子中，一個事務包含“生成一個請柬”和“相應地發送一封郵件”兩個操作。只有事務中的操作全部成功，才可以判定事務成功。否則事務中的任何一個操作失敗，即認定事務失敗。事務失敗可以中止運行，也可以跳過失敗的事務，繼續運行下一個事務。當增加機器人數量時，只需通過簡單地分配事務，即可達到充分利用機器人效能的目的。
3. 凡是需要人工輸入的環節，就一定會出錯，因此絕對不能信任人工輸入的數據。那么對於人工輸入的問題，有幾種辦法可以提高穩定性。
a. 對人工輸入進行嚴格約束和校驗，拒絕不符合要求的數據。（不推薦，但有時候不得不這么干）
b. 設計時加入一定的彈性以實現容錯的能力。
c. 減少人工輸入的環節，減少人工輸入的數據量。
d. 設法盡可能地為人工輸入進行輔助，比如彈出相關提示，給出格式示例等等。
4. 當需要處理文件關系時，有幾種辦法可以在文件之間體現關聯：
a. 用某種命名規則來確保文件關聯。比如說，有一個Excel文件為叫小明_總成績.xlsx，而另一個Excel文件為小明_語文成績.xlsx，這里文件的命名規則是“學生姓名_科目成績.xlsx”，那么可以認為小明_總成績.xlsx和小明_語言成績.xlsx是相關的文件。
b. 建立一個表格用於存儲文件關系。這樣文件可以通過這張表來查找，不需要特別指定命名規則。比如
| 學生姓名 |
總成績文件 |
語文成績文件 |
| 小明 |
AAA.xlsx |
BBB.xlsx |
| 小紅 |
CCC.xlsx |
DDD.xlsx |
5. UiPath Studio項目目錄里的文件在每次發布到UiPath Robot時都會相應地新建，因此需要持久化存儲的數據（比如配置文件）不應該存儲在UiPath Studio項目目錄里。建議用Get Environment Folder(UiPath.Core.Activities.GetEnvironmentFolder)存儲在某個系統自帶的文件夾下（推薦保存到MyDocuments）。
6. 機器人往往需要能夠自動登錄各種系統，而各種系統往往需要憑據（用戶名+密碼）才能登錄。可以將登錄憑據保存在Windows自帶的憑據管理器，然后用Get Secure Credential(UiPath.Credentials.Activities.GetSecureCredential)去讀取。需要輸入密碼時不要用Type Into，必須用Type Secure Text。采用Get Secure Credential + Type Secure Text的組合，機器人可以做到全程不接觸密碼明文，相對安全。
7. 使用Get Text或者Get Attribute從網頁上獲取的原始內容應該用Log Message保存到日志里以便於查錯。
8. 在Excel中填入URL會被自動轉化為超鏈接，但是如果UiPath需要讀取這個URL，那么需要移除這個超鏈接，否則會報錯。
9. 注意生產環境與開發、測試環境的差異，容易導致意想不到的異常。也因此，大體上，開發流程所需的時間≈調整穩定性所需的時間≈遷移到新環境測試調整所需的時間。任何環境因素的變化都需要重新測試以確保穩定性。
10. 加入源代碼管理的時候，UiPath Studio里項目目錄.screenshots下的內容也必須全部加入源碼管理。
11. 每次運行都需要保存一個配置文件的副本，以備查錯。
12. 如果需要建立自定義日志，流程運行的最初步驟將已存在的"C:\Users\你的用戶名\AppData\Local\UiPath\Logs\日期_Execution.log"文件改掉名字，然后在運行中用Log Message記日志。UiPath會自動創建新的日志文件，然后在運行的最后將這個日志文件復制出來即可。通過這種方式可以簡化自定義日志的工作，而且必要時可以改變日志級別以獲取更多信息用於查錯。
13. 流程較長時，可以分割為多個階段來開發，每個階段流程用一個.xaml文件來處理。分割的原則大體上是，給定機器人一個文件A，機器人經過階段性的UI或者后台處理，一定可以產生文件B。那么只需要將A的完整路徑作為這個.xaml文件的輸入參數，而將B的完整路徑作為輸出參數，即可很方便地開發調試這個流程。當有多人一起協作開發同一個流程時，只要這樣分割為多個小流程，並且詳細約定好中間文件的各項內容，就可以同時進行。這種方式也稱為“面向接口編程”。
14. 當RPA項目團隊有多人開發時，每人負責一個流程的組織模式有可能造成每個流程都趕不完的局面。不如將單個流程划分成更小的流程，一起協同進行一個流程的開發，這樣團隊在預期的時間內可以完成盡可能多的流程，而不是制造大量完成度參差不齊的流程。特別是，團隊成員可以不需要了解流程的全貌，只了解流程的局部即可，實現流水線式的開發管理。而對流程掌握最全面的成員，可以少承擔一些開發工作，但需要負責不斷地進行集成測試，由這個人來負責交付完整的UiPath Project。
15. 編輯Selector時，要善用相對Selector和部分Selector，例如Anchor Base，Element Scope，Find Relative Element， Get Ancestor。
16. 開發的最初不應該加入任何Try Catch，以便在測試中發現會產生Exception的位置，以及Exception的類型，並進行相應地處理。即使邏輯實現確實需要加入Try Catch，也切忌直接Catch System.Exception，防止預期外Exception類型無法在Catch中正確處理。但最后一定要在最外層套一個Try Catch，以處理預期外的Exception。
17. Get Text獲取的數據是UiPath.Core.GenericValue類型，需要輸出為特定格式字符串的時候，可以嘗試使用Format Value（UiPath.Core.Activities.FormatValue）。
18. 目前大多數RPA的使用場景只是數據處理領域ETL工作的變種，因此可以盡量參考ETL的設計思想和有益經驗。
19. 每個Activity都必須命名，必要時還須加上Annotation進行解釋說明。參數和變量也是如此。