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

はじめに

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

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

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

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

UiPathには、公式のコーディング規約があり、その目的は以下のように書かれています。

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

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

ルール仕組み）一貫性

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

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

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

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

名称	登場年	説明	リンク
ReFramework	2018年	大規模の分散処理の可能なフレームワーク	参考
Attended Framework	2018年	シンプルな処理のためのフレームワーク	参考

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

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

メンバーが作成したフローは、モデル（お手本）こそあっても「各個人の書き方・色」が出ます。なので、他人目線での指摘、コードレビューは必要です。レビューのチェックポイントは、前述の公式コーディング規約の中にサンプルがあります。レビュー粒度も「あまり細かくこだわらない」ほうが良いですが、大枠としての統一感は担保出来るようにしたいところです。

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

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

可読性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

再利用性

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

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

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

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

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

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

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

終わりに

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

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