【UiPath】品質の高いコードとは（前編）

# はじめに

この投稿は、RPAツール「UiPath」の 実装ポイントをまとめたものです。

量が多いので、記事を数回に分けます。今回は、ルール仕組み編 として「一貫性・可読性・再利用性」について書きます。

UiPath Adventカレンダーの 2日目 の記事でもあります。

https://qiita.com/advent-calendar/2021/uipath

# UiPath公式の「品質の良いコード」とは？

UiPathには、公式のコーディング規約があり、その目的は以下のように書かれています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154139/e2d35812-460e-66b3-9429-623ce23785d9.png)

https://www.uipath.com/ja/blog/corporate/uipath-coding-standard

これを以下のように分類し「コーディング規約に書かれている事」と「自分が見聞き、経験、実践している事」をミックスして、紹介します。

```
ルール仕組み
　◆ 一貫性 　(命名規則や処理の構造などが複数のワークフローで統一されている)
　◆ 可読性　 (読みやすく、処理の意図が把握しやすい)
　◆ 再利用性 (作成済・テスト済のワークフローをそのままの形で再利用しやすい)
安定性 効率性
　◆ 効率性 　(少ないリソースで高速に動作する)
　◆ 安定性 　(安定して動作する)
保守
　◆ 保守性 　(どこを修正すべきか分かりやすく、また修正による影響が予測しやすい)
　◆ 信頼性 　(エラーが発生しにくく、また発生した場合でも回復が容易である)
　◆ 安全性 　(機密情報を不正アクセスから守る)
```

# ルール仕組み）一貫性

`⚫ 一貫性 　(命名規則や処理の構造などが 複数のワークフローで統一されている)`

まず最初は「ルール・仕組み」作りの話から。
「一貫性」のために出来る、具体策としては以下があげられます。

```
- 1）チーム内のコーディング、作り方のルールを決める
- 2）モデル（お手本）フローを作成し、計画的に見直す
- 3）作成したフローを、人の目で見直す
- 4）作成したフローを、ツールでチェックする
```

UiPathには公式の「フレームワーク」と「コーディング規約」があるので、参考になります。有名なフレームワークは以下の2つです。

| 名称 | 登場年 | 説明 | リンク |
|:-|:-|:-|:-|
| ReFramework | 2018年 |  大規模の分散処理の可能なフレームワーク | [参考](https://www.uipath.com/ja/resources/knowledge-base/using-uipath-reframework) |
| Attended Framework | 2018年 | シンプルな処理のためのフレームワーク | [参考](https://marketplace.uipath.com/ja/listings/attended-framework)| 

上記の「公式フレームワーク」「公式コーディング規約」は、細かい実装方法やルールが曖昧な点もあるので「たたき台」にして、自分たち用にカスタマイズする必要があります。コツとして「あまりガチガチなルールにしない」ほうが、開発のスピード感が出ます。

https://el.jibun.atmarkit.co.jp/horus/2018/07/post_21.html

ルール決めと同時に、お手本としての「モデルフロー」を作成し、開発メンバー間で認識し・ルールを共有します。実装していると「この部分は、こうすれば良かったな」と思い返すことも多いので、モデルフローは定期的に見直して、ブラッシュアップしていくと、より完成形に近づきます。

メンバーが作成したフローは、モデル（お手本）こそあっても「各個人の書き方・色」が出ます。なので、他人目線での指摘、コードレビューは必要です。レビューのチェックポイントは、前述の公式コーディング規約の中にサンプルがあります。レビュー粒度も「あまり細かくこだわらない」ほうが良いですが、大枠としての統一感は担保出来るようにしたいところです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154139/49806dd5-3bfd-7726-9077-0c6556f81bab.png)

また、UiPathStudioには「ワークフロー アナライザー」という静的コードチェックの仕組みが付いているので、まずこのツールでチェックをすることをお勧めします。

https://docs.uipath.com/studio/lang-ja/docs/about-workflow-analyzer


変数名のルールチェックやスコープチェックなどの「人の目でチェックが大変」な点は、解析ツールを利用してチェックすると見落としが無くなります。

https://marketplace.uipath.com/listings/jpn4jogqcesx9gr9y37nz



# 可読性

`⚫ 可読性　 (読みやすく、処理の意図が把握しやすいこと)`

次に「コードの見やすさ」の話です。
「可読性」のための具体策は、以下があげられます。

```
- 1）コードの書き方に統一性をもたせる（フレームワーク・テンプレートの活用）
- 2）処理の全体像が分かるワークフロー（xamlファイル）を作る
- 3）ファイル名や変数名などを、意味の理解できるものにする
- 4）コメントをシンプルに的確に簡潔に書く
```

UiPathはローコード開発ツールで「部品を合わせてコードを書く」形なので、コードが長くなりがちです。更に「誰でも簡単に開発できる」という反面、「書き方がバラバラに」になることも。回避するためには「フレームワーク」や「テンプレート」を利用して「書き方」をある程度「統一」する必要があります。

https://docs.uipath.com/studio/lang-ja/docs/project-templates

それでも、作成された処理フローが「スパゲッティ状態」になり、可読性が落ちることもあります。「このファイルを見れば、全体の流れがわかる」xamlファイルを用意して、処理フローの見通しを良くすると、全体理解が楽になります。

https://ssaits.jp/promapedia/jargon/spaghetti-code.html

良く「フローチャートとシーケンス、どっちで書いたほうがいのか？」という話になりますが、「シーケンスじゃないとダメ！」ではなく、それぞれの特徴を理解して使い分けたいです。初学者・初心者にとっては、フローチャートのほうが書きやすいかもしれません（シーケンスに落とすためには、頭の中でフローが書けていないと厳しいから）

https://docs.uipath.com/studio/lang-ja/docs/workflow-design

個人的には、「上位の処理はフローチャートでキレイに書く」ことにして「下位の処理は基本はシーケンス、場合によってはフローチャート」で書くようにしています。

|  | フローチャート| シーケンス |
|:-:|:-|:-|
| 特徴  | 上下左右に自由に処理を配置可能な形<br>複数の分岐ケースを書きやすい<br>シーケンス内の処理は開かないと見れない | 上から下に処理が流れていく形<br>ぱっと見やすい<br>シーケンス内の処理は開閉が自由  |
| 向いてる  | 全体処理の流れを把握したいとき<br>大枠の処理を書くとき | ある程度 個別の処理<br>単体テストしたいブロックの処理 |



https://www.persol-pt.co.jp/persolrpa/rpalounge/column103/

https://osana-kakuei.com/%E3%80%90uipath%E3%80%91%E3%82%B7%E3%83%BC%E3%82%B1%E3%83%B3%E3%82%B9%E3%81%8B%E3%83%95%E3%83%AD%E3%83%BC%E3%83%81%E3%83%A3%E3%83%BC%E3%83%88%E3%81%8B/


<br>

ファイル名や変数名などのネーミングも「誰にでも分かりやすい」ものにしたい。
変数や引数やxamlファイルなどを「日本語でもOK」にすると分かりやすくなりますが、例えば変数名を日本語にすると、以下のような「メリット／デメリット」があります。

| 変数を日本語にすると？ | 内容 |
|:-:|:-|
| メリット | とにかく分かりやすい<br>専門用語の英訳に困らない  |
|デメリット | 変数名の自動補完が利用しにくい<br>最初は気持ち悪い  |

また、変数に型名のプレフィックスを付けると、型の情報が分かりやすくなりますが、付けるのが面倒だったりします。（例：int_ループインデックス）

| 変数に型名を付けると？ | 内容 |
|:-:|:-|
| メリット | 変数を見ただけで型が分かる  |
| デメリット | 無数にある型のルール決めが面倒で揺らぐ<br>（例：list型は、lst_ or list_ ？）  |

上記の「日本語変数名」「型名プレフィックス」のルールは、`「変数名は日本語でないとダメ」「型名を付け無いとダメ」` という***厳しいルール***ではなくて、`「変数名は日本語でもOK」「分かりやすくなるなら型名をつけてもOK」` という ***基本（書き手に任せる）ルール*** のほうが良いと思います。（分かりやすく・書きやすければ良いという話）

<br>

また、処理が難しい／分かりづらい箇所は「コメント」で補足しますが、コメントは「短く、何をしてるのか？」をシンプルに書かないと、逆にコメントで迷子にさせてしまうので、要注意です。

https://dekiru.net/article/17136/

コメントアクティビティは「使いにくい印象」がありますが、改行を入れて 箇条書きに書くと「仕様を伝える文章」として使えます。

https://forum.uipath.com/t/topic/263030



# 再利用性 

`⚫ 再利用性 (作成済み・テスト済みのワークフローをそのままの形で再利用しやすい)`

次に「流用性・横展開」の話です。
「再利用性」のための具体策は、以下があげられます。

```
- 1）処理を分割する習慣をつける
- 2）共通的な処理は、ライブラリで管理する
- 3）xaml単位で、簡単に動作確認できるようにする
- 4）実装が難しい処理は、カスタムアクティビティで作成する
```

フローを書いている際に、データ取得やデータ加工、Uiの操作など、処理内容をある程度「分類」しながらxamlファイルに切り出しておくと、その中から共通処理が生まれたりします。

結果、複数のロボットで使用したい「共通処理」が出来たときは、ライブラリで管理することで共有できます。

https://www.uipath.com/ja/resources/knowledge-base/how-to-manage-packages

フローを実装する場合は、xaml単位で処理を切り出していきますが、xamlファイル単位でテストできるようにします。右クリックの「テストケースを作成」機能を利用して、テスト用xamlを作成してもいいですし、以下のように簡易的なテストが実施できる方法もあります。

https://qiita.com/miya_gis/items/48150c2a41dda31da57f

UiPathでの実装が難しい場合、または独立した機能セットを作りたい場合は「カスタムアクティビティ」で実装すると良いかもしれません。ただし、作成やメンテに技術力が必要です。

https://qiita.com/masatomix/items/1f63513e80313a99faeb


# 終わりに

いかがでしたでしょうか？今回は前編として、ルール仕組み の「一貫性・可読性・再利用性」について書きました。

この記事が参考になったら、 LGTMをお願いします。閲覧ありがとうございました。