はじめに
この投稿は、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をお願いします。閲覧ありがとうございました。