はじめに
この投稿は、RPAツールの「UiPath Studio」で「読みやすいフロー」を書く方法 について、個人的にまとめたものです。量が多いので 数回に分けて書きます。
2023年7月開催の「UiPathブログ 発信チャレンジサマー」の7日目の記事でもあります。
前回は「概要編」として、以下の記事を紹介しました。
今回は「変数・引数」について。
目次
# 1）Studioにおける「変数・引数」
# 2）変数・引数は「分かりやすさ」が大事
# 3）変数の良くない使い方
# 4）変数引数を見やすくするコツ
# 5）ワークフローアナライザーでチェック
1）Studioにおける「変数・引数」
変数とは一般的に「値・状態を格納する箱」と言われます。
UiPathでも同様で、変数は「Xamlの処理の中で値・状態を格納する」ために使用されます。 引数は「Xamlフローを呼び出したときに渡される変数」のことです。
UiPath Studio では「変数パネル」で変数引数の設定ができます。
「Studio version22.7」以降では「データマネージャーパネル」でも変数引数を設定できます。
最近はこの「データマネージャー」を推している感じがあり、設定次第では変数パネルが表示されません。
データマネージャーを使うと「フローの縦幅が長く取れる」「タブを切替え不要で変数引数を一覧で見れる」「スコープが狭い隠れ変数を見逃さない」「グローバル変数を管理できる」などのメリットがあります。
また、Studio上の「変数・引数」には、ルールがあります。
| 項目 | 内容 |
|---|---|
| 長さ | 制限は無い（？）が、推奨は３０文字以内 |
| 使用できる文字 | 数字・英字・アンダーバー |
| 使用できない文字 | 記号・予約語 |
| 先頭文字 | 数字はダメ |
| その他 | 日本語の使用可 |
変数引数の「長さ制限」はありませんが、ワークフローアナライザーでは、変数の文字列は「３０文字」とされています。長いと「可読性が下がる」ためでしょう。
数字英字以外は「アンダーバー」しか使えません。「And・Or・Byte」等の.NETの予約語も使用できません。
日本語の使用は可能です。英語とのmixも可能です（例：dt_価格マスタ）
2）変数・引数は「分かりやすさ」が大事
変数や引数を見た時に「分かりにくい」と可読性が落ちてしまい、フロー自体が読みにくくなります。
例えば、以下のような「変数」は、どうでしょうか？
・num ・・・番号の数字っぽいけど、なんだろう？行番号とか？
・データ値 ・・・データという言葉が広すぎて予想できない。商品名とか？
・str_AriFlag ・・・フラグなのにString型？フラグONのときの文字は「ON」or「True」？
・AccountsReceivable ・・・どういう意味だろう？翻訳すると「売掛金」という意味だった！
どれも「パッと見」では分かりません。「曖昧／嘘の情報／長すぎる」のが分かりにくさの原因です。
もし分かりやすくするなら
・num ⇒ 「rowNumber」や「行番号」など
・データ値 ⇒ 「商品名」など
・str_AriFlag ⇒ 「bln_Exists」や「商品ありフラグ」など
・AccountsReceivable ⇒ 「売掛金金額」など
など、より「具体的な情報」を「シンプルに」示すようにすると良いでしょう。
見たときに「何の値なのか？」を「違和感なく」伝えると、他の人にも優しくなって可読性が上がります。
個人的には、以下を意識しています。
・できる限りシンプルに（短くズバッと）
・自然な名前（変に思われないように）
・スペルミス・誤記はダメ（もったいない）
・少し時間をおいて見直す（頭を冷やしてから再度見る）
・他の変数と足並みを揃える（書きっぷりを合わせる）
・他の人に見てもらう（意見をもらう）
自己チェックには限界があります。現場の書き方・ルールもあるでしょう。
他の人に相談したり、レビューしてもらうことで、プロジェクトに合った書き方を模索することが大事です。
① 名前付けにこだわる
「すっと理解できる」「誤解や疑問のない」「客観的に見て相応しい」名前が良い
② 周囲・周りのメンバーに合わせる
独りで決めない。「プロジェクト」「メンバー」に合わせた書き方を探す
UiPathでは変数引数に「日本語」も使用可能です。日本語のほうが「自然な名前」を付けやすく便利です。
日本語で書いてもOK（日本語なら書きやすく分かりやすい）
「型名」を付けても良いかも（その方が良ければ）
中身をイメージしやすくするために、先頭に型名をつけるのも有効です。
個人的に、配列・リスト・ディクショナリ・データテーブルなどの「複数の値から構成されるもの」は、型名をつけると区別できるので、分かりやすいと思います。（先頭に型名が付いていれば、名前の後ろに「リスト」等の文字が不要になるし。）
dt_ ：DataTable型
lst_ ：list型
ary_ ：Array型
dic_ ：Dictionary型
例）商品番号のリスト ⇒ lst_商品番号
少し変わった変数も、先頭に型名を付けることで「違う」という意思表示ができます。
elm_エラーメッセージ ・・・ 画面上のエラー要素を取得した「UiElement型」の変数を示す
大事なのは「ルール云々」ではなく「分かりやすさ・伝わりやすさ」を意識すること。
後で保守することも考えて、後で読み返した時に「優しくなる」ようにしたいものです。
3）変数の良くない使い方
UiPathに限らず「変数の使い回しは避けるべき」です。バグの温床になりがち。
ただ「変数をやたらと増やしたくない」という気持ちは分かる。その場合は
・初期化を必ず実施して事故を起こさない
・分かりやすいコメントを付ける
等の工夫が必要です。
「ループの中で使い回す変数」の扱いが悪く（初期化していないなど）、バグになることが多い。
「ループ」と「変数使い回し」は特に注意が必要です。
Studioでは「変数スコープは狭い方が良い」という話もあり「取り間違え・使用ミス」を未然に防ぐ観点ではその通りなのですが、可読性を考えると「スコープが狭い」と変数自体を見逃してしまうデメリットがあります。（変数パネルでは、現在いるシーケンスの変数しか表示されないため、スコープの狭い・隠れた変数を見つけることが難しい）
可読性を考えると、スコープが狭い変数は「悪／デメリットが大きい」です。
ただ、前述の「データマネージャー」を使用すれば、xaml内の変数すべてを一覧で確認できるので、「データマネージャーを使って変数を管理しよう！」というプロジェクト／チームなら、スコープを狭くするのもありでしょう（現時点では、データマネージャーを使いこなしている人は少ないと思いますが）
ちなみに、Studio 23.4 で「宣言不要の変数」機能が追加されました。（下位互換は無いため、使用は注意が必要です）
将来的には「局所的に使用する変数は変数宣言しない」ほうが良くなるかもしれません。
4）変数引数を見やすくするコツ
実装時に「この変数・引数が必要だな」と追加していくと、不要な変数が残ったり、変数の並びがバラバラになったりします。
変数引数パネルで見た時に「並びがきれい」例えば「同種類の変数は纏める」などの工夫があると「変数から処理内容を予測出来る」ので、可読性が上がります。
この時に「引数に移動／変数に移動で並びをキレイに揃えられる」ことを知っておくと便利です。
見やすさとは違いますが、新しく変数を作る際に「すでにある変数の型を選択する」ことで、型選択プルダウンに該当の方を表示させることが出来ます。
また、変数引数に注釈／アノテーションを付けたものを見かけますが、注釈は確認しにくいので
・注釈が無くても、見た目で分かりやすい名前にしたほうが良い
・引数の説明が必要なら、Xaml上部に「引数説明」を書いたほうが分かりやすい
など、読み手を意識した実装をしたほうが良いと思います。
5）ワークフローアナライザーでチェック
ワークフローアナライザーは、UiPathStudioに付いている静的コード アナライザーです。
高品質で信頼性のあるコードか？をチェックしてくれます。
ワークフローアナライザーのチェック項目に「変数引数」についてのチェック項目があり、例えば前述の「変数の名前は30文字を超えないようにする」も、チェックしてくれます。具体的なチェック項目は以下です。
| 名称 | 扱い | 内容 |
|---|---|---|
| ST-NMG-001 - 変数の命名規則 | 警告 | 変数名が特定ルールに従っているか（正規表現でルールを指定） |
| ST-NMG-002 - 引数の命名規則 | 警告 | 引数名が特定ルールに従っているか（正規表現でルールを指定） |
| ST-DBP-002 - 多数の引数 | エラー | ワークフローの引数が多いと分かりにくい |
| ST-NMG-016 - 引数の長さが最大文字数を超過 | 警告 | 引数の名前が長いと分かりにくい |
| ST-NMG-005 - 変数が変数をオーバーライド | 警告 | ワークフロー内の変数名はスコープが違っても同じではダメ（危険） |
| ST-NMG-006 - 変数が引数をオーバーライド | 警告 | 変数と引数で同じ名前になっていると、混乱を招く |
ワークフローアナライザーを使うと、コードの品質・可読性があがるので、ぜひ使ってみてください。
終わりに
以上「変数・引数編」でした。
この記事が参考になったら、 いいね をお願いします。閲覧ありがとうございました。