【いきなりStudio７】代入アクティビティでガチろう～変数と引数の取り扱い～最低限の命名規則を意識しない＝キラキラネームは、ガチラーから嫌われる( ´∀｀ )
さてと、前回
オブジェクト指向言語の醍醐味である、
ワークフロー ファイルの呼び出し
まではやったので、今回は
代入アクティビティ
で、
xamlファイル間の値のやりとり
について、やってこ( ´∀｀ )コイツをしっかり理解して使いこなせると、
変数と引数で変幻自在に遊べて、
ガチりの幅がグンッと広がる
ので、今回も、
じっくり考え方とか作法を交えながら
紹介してくや( ´∀｀ )
※ジムで二回風呂入って、ビール片手に今回も書いてます( ´∀｀ )
代入アクティビティ
がUiPath 公式なんだけど、
内容薄っす👀💦
ちょいと操作を
前回までにやってたソース
アクティビティを追加
値を設定の中身をクリックして、編集状態にする
ここでポイント①：ショートカットキーで作成
変数：Ctrl＋Kキー
引数：Ctrl＋Mキー
で作れるので、ここではデモンストレーションで作るだけだから( ´∀｀ )
変数：VariableValue（処理の間で変化する値）☞demoVar
引数：ArgumentValue（処理の間で引き渡す値）☞DemoArg
て前提で、まずは変数を。
アクティビティでも確認して～～～
変数のデータ型：String
スコープ：RobotMain（＝このxamlファイル全体）
になってることを確認出来た💃
次に右辺の値を適当に、、、
んで、次は同じ感じで代入アクティビティをもうひとつ追加して、
※いつも思うが、「左辺の変数」て変数しか設定できないような項目名( ´∀｀ )
と、ここで少し変数と引数の違いを。
少しと、言いつつめちゃくちゃ重要( ´∀｀ )
ここでポイント②：変数と引数（それと定数）の違い
さっき、
変数：VariableValue（処理の間で変化する値）
引数：ArgumentValue（処理の間で引き渡す値）
って書いたんだけど、そのまんま
変数：上から下まで処理を実行する間で、処理中に値が変わっていく値（例：行数など）☞値が変わるから変数
引数：各xamlファイル間なんかで、値を引き渡してやり取りする値（例：ファイルやフォルダのパスなど）☞値を引き渡すから引数
なイメージ( ´∀｀ )。ついでに定数も加えると、
変数：上から下まで処理を実行する間で、処理中に値が変わっていく値（例：行数など）☞値が変わるから変数
引数：各xamlファイル間なんかで、値を引き渡してやり取りする値（例：ファイルやフォルダのパスなど）☞値を引き渡すから引数
定数：上から下まで処理を実行する間で、処理中に値が変わらない値（例：消費税など）☞値が変わらない＝定まっているから定数
こー書くと頭の固い「正しい日本語」とかゆー人で、
厳密に言えば違う
みたいなツッコミを入れてくる輩がいるんだけど、じゃあそもそもプログラミング言語の黎明期では、電子計算機ってゆーくらいだから、最初はあくまでも、
2進数の0と1しかなく、
値が数＝数値だけしかなかった
ので、
変数：VariableValue☜直訳すると、変値でないとおかしい
引数：ArgumentValue☜直訳すると、引値でないとおかしい
定数：ConstantValue☜直訳すると、定値でないとおかしい
はずなモノを、
値＝数
って訳してしまってるんだけど、今や、文字列やらデータテーブル型、辞書型、配列などなど、
本来で言えば数値でないモノまで全て、
数って言ってるのが、
厳格に言えばそれこそおかしくないのか( ´∀｀ )
ってなってしまってるんだよね～～～。
アクション・リサーチと乖離した研究職ではないので、実務では
あくまでも、
数＝値☞そんなもん
くらいなイメージで、
当たり前の作法だけ理解して、効率よく
作りたいものが作れたらそれでいいので、
理解しておく方がいい。厳密に言えばとかゆーてたら、
すぐに作れるロボットも作れなくなるぞ( ´∀｀ )
ここでポイント③：何故、変数と引数で書き方が違うの？
変数☞demoVar＝小文字始まり
引数☞DemoArg＝大文字始まり
なんだけど、これは前回
示した、
【キャメルケースの基本】
アッパーケース（大文字始まり）：ファイル名、フォルダ名、引数名
ロワーケース（小文字始まり）：変数名、関数名
で、UiPath は民主化されたテクノロジーで、ローコードツールなので、そこから入っている人は、あんま意識することがないんだけど、例えば、さっきのソースの引数を逆に小文字始まり（ロワーケース）で
変数も引数も、
同じく小文字始まりにしちゃうと、
ぱっと見、
どちらが変数でどちらが引数か区別がつくか❓
って話( ´∀｀ )で、結局
いちいち確認しないと分からない
＝余計な手間がかかる
ので、
変数：小文字始まり☞ロワー
引数：大文字始まり☞アッパー
って区別してるだけの話。だから、この規則性を共通理解しておけば、
ここでポイント④：StudioXでやってたみたいに日本語にしちゃえばいいじゃん❓👀
これに関しては、【UiPath StudioXの遊びかた】の
でやってたソースをStudioで開くと、
■変数
Studioも出来なくはないんだけど
■引数
何故かと言えば、これまでの【いきなりStudio】でゆーてきたとおり、StudioXでは、開発者に✓を入れない限り、そもそも
ワークフロー ファイルを呼び出しアクティビティが存在しない
☞ファイル間で値をやり取りする
って概念が存在しない
＝引数って概念がなかった
から成立する話で、、、ここでポイント②でゆーてた話同様、
全てを日本語にできなくはないけど、
引数と変数が存在するStudio
で、
これが、
変数、引数って付いてなかったら、
ぱっと見でどっちが変数でどっちが引数か分かるか❓👀
って話。なので、立て付けの機能として、
ワークフローの呼び出しがなかったStudioX＝変数しか存在しない＝日本語で書いても支障はない
ワークフローの呼び出しがあるStudio＝変数と引数が存在する＝日本語で書くとどっちが変数か引数かぱっと見わからない
ので、
ロワーとアッパーで使い分けた方が、
開発が効率的になる
って話
一歩前へ：じゃあなんで単純にvarとArgじゃなくてわざわざ、demoVar、demoArgみたいに修飾語を付けてるの❓👀
これもよく、新人ちゃんから現場では聞かれる話で、
「変数だからvar（例：Excelの行数ならrow、回数ならcnt）、引数だからArg（例：Excelのファイル名ならFileName、ファイルパスならFilePath）じゃいけないんですか？」
があるんだけど、前回示した
メゾスコピックな＝構成要素単位の処理
で
必ず一個しかファイルを開かない
回数を一回しかカウントしない
なんてものばかりだと思う❓👀
行数を全部rowってやってしまうと何のシートの行数なのか
ファイル名を全部FileNameってやってしまうと、どのファイルなのか
が、
ぱっと見分からない
＝ソースを辿らないといけなくなる
ので、例えば、Configファイルを取り扱うとして、
修飾子＋変数名：現在のシートの行数☞configFileCurrnetSheetRow
修飾子＋引数名：Configファイル名☞例：ConfigFileName
てな感じで、
命名規則を定めておくのが普通
前回ゆーたみたいに
もう一歩前へ：Studio開発での原則
最初から、今後の改修を意識しながら新規でも開発する＝作法を身に付ける（以下、省略）
ぱっと見、時間がかかるのと時間がかからないのは、どちらの方が
改修コスト（時間とか作業工数）
がかからないでしょう❓( ´∀｀ )
って話。なので、これも前回ゆーたけど
シンプルイズビューティフル
で一定の規則で共通理解をしておけば、
ソースがややこしくならない
☞改修が簡単になる
＝最初からそれを意識して作っておけ
ってだけの話( ´∀｀ )
（ま、肌感覚の話なんで、ここはいくらゆーても素人の自分流＝オリジナリティって勘違いしてヤル奴はやるんだが( ´∀｀ )）
さらにもう一歩前へ：うちの現場では、変数や引数の頭に、データ型_変数名や、データ型_引数名にしろってゆーてるけど、、、
これも結構、メインフレームの時代から、
オブジェクト指向言語の醍醐味＝再利用
をよく理解してないまま、
積み上げ方式
の弊害が残ってる現場で多い👀💦
（マジで引くレベル( ´∀｀ )）んだけど、
あくまでもシンプルに、
どっちが読みやすいか＝管理しやすいか
で考えたらいい。
実際、ここまでの操作でやった変数や引数名を
でやっちゃうと、同じデータ型の場合、
ぱっと見、区別がつかなくなる
し、さっきまでゆーてた
【キャメルケースの基本】自体が破綻する
でしょ( ´∀｀ )そこまでしてデータ型なんてわざわざ頭に付けなくても、データ型を確認したいだけなら、それこそ調べたいときに、
むしろ、こっちが問題なんだけど、作成当初は、String型だったのが、要求変更があってデータ型が数値型に変更になったときに
って話。全部一括管理出来てれば変更は可能だけど、語彙力がない前任者なんかが
データ型以外、似通った名前で既にほかに変数や引数名があった場合どうするの❓👀💦
って話。ま、だから普通は、ひとつ前でゆーたみたいに、
修飾子＋変数名
修飾子＋引数名
って感じで、プロジェクト全体やxamlファイル内で、
ユニーク（一意性）のある名前を付けて管理する
んだけどね( ´∀｀ )だって、変数や引数も、UiPath って開発環境の中では、
で示した
データ
に過ぎないから( ´∀｀ )だから実際、StudioXでもStudioでも、作成（定義）した値は全て、
データマネージャ
で管理してるでしょ( ´∀｀ )ホイ、おそらく全てここまで読むと繋がってきたところで、
関連記事：
で過去に紹介してるから参考にどうぞ～～～( ´∀｀ )
さてと、なっがい（しかし、重要な）前置きが終わったところで操作に戻って、
引数は値を引き渡す（やり取する）だけなんで
ここまでの操作は、初期値を設定（＝初期化）してるだけなので～～～
で触れた
シーケンスアクティビティ
でもって、前回
ワークフロー ファイルの呼び出しアクティビティ
でやった感じで
で、前回まででやった感じで、新しく追加したファイルに
で、
メッセージをログアクティビティを追加
しておいて、RobotMainに、
ワークフロー ファイルの呼び出しアクティビティ
をドラッグ＆ドロップで追加
で、ReadConfig.xamlファイルに、今度は代入アクティビティを使わずに直接
てな感じで、引数を追加。RobotMainに戻ると、
一回Cancelボタンでキャンセルしておいて、
さっきの一歩前へで、やってたstr_付きの変数名と引数名を元に戻して、
ReadConfig.xamlに戻って、代入アクティビティで、冒頭の変数作成と同じ要領で、
変数を設定。さらに、代入アクティビティを追加して、
で、このまま実行すると、実はMain.xamlにも
（まだ、RobotMainからMain引き渡す値
がねーし( ´∀｀ )）
OKボタンだけをクリック
一旦ここまででファイルを全部保存して～～～
実行
引き渡した値のメッセージをログしてなかったので～～～
RobotMainに、
で保存して、再実行して、出力パネルを見ると
入出力でReadConfig.xamlからRobotMain.xamlに引き渡した
Config読み取り実行＝引数の値
が返ってきてる💃とまあ、ここまでで今回メインな
変数と引数の値のやり取り
のイメージが湧くように操作をメインで話したんだけど、
ここでポイント⑤：引数をインポートは方向が命
今回は、
⇔
なんだけど、もっと厳密にInとOutを区別して
出力用の引数をひとつ追加して、
入力用と出力用の引数を明確に分離
ReadConfig.xamlにアクティビティを追加して、
オレンジになっているので～～～
より分かりやすくしたいのであれば、RobotMain.xamlを
実行すると
つまり、方向性まで意識して引数を定義すると
方向が入力：DemoArg→InReadConfig ☞ Name←Valueな方向性＝右から左
方向が出力：InReadConfig→DemoArg ☞ Name→Valueな方向性＝左から右
方向が入出力：InReadConfig⇔DemoArg ☞ Name⇔Valueな方向性＝双方向なやり取り
って違いが分かると思う( ´∀｀ )
とここまでは、あくまでもデモで教室事例なので、さっきの
「さらにもう一歩前へ：うちの現場では、変数や引数の頭に、データ型_変数名や、データ型_引数名にしろってゆーてるけど、、、」で示したみたいに
頭にInとかOutとか方向を明示する文字を付けると、既に分かりにくくないか❓( ´∀｀ )
てのが出てくるでしょ( ´∀｀ )
実は、単純に考えると、OutReadConfigArg引数って、
要は、実行結果を返してるだけ
だから、わざわざ引数名の頭にOutだのInだの付けなくても
RunResult：実行結果
にして、
変更しても、
全く同じ実行結果が返ってくるだけなんだどね( ´∀｀ )
ここまでのまとめ：やったことない人にはマニアックに見えるかもしれないけど、
如何に、ワークフローファイル（＝前回やったオブジェクト）間でただ、
値をやり取りしてるだけ
ってのが分かるでしょ( ´∀｀ )で、それがこれまで滔々と話してきた
変数とか引数の命名規則ひとつで、読みやすい（＝管理しやすい）モノになるか否かが変わってくるか
が分かるでしょ( ´∀｀ )ま、ここの感覚を解説するのに必要だったから、ちょっと意地悪な回り道で、
str_だの、InだのOutだの頭に付ける
☞普通の現場でよく陥りがちな命名方法
なんかをしなくても、
設計（コンストラクション）を意識
しておくと、実は、
ワークフローの最終的な実行結果を返すだけ
☞RunResultみたいな引数でOK
ってのが分かるでしょ( ´∀｀ )さらに、どのxamlファイルで実行したかまで分かりやすくしたければ、
一発でどこから、どんな処理の値が出力されてるか分かる
から、
単純に、
RunResult
ってするより分かりやすいでしょ( ´∀｀ )
で、Main.xamlの変更可能性も考えて、
ここまでのソースをリファクタリング
RobotMainの引数と変数を、
■RobotMain
■Main.xaml
だって、Main.xamlは、
結局、RobotMainの最終的な処理結果が引き渡されるだけ
だから、
RobotMainResult：ロボットメイン処理の処理結果
☞引数名としては十分
だからね( ´∀｀ )
Studioだと、StudioXの初期設定になかった
ワークフローファイルの呼び出しで値をやり取りしてるだけ
（☞オブジェクト指向言語の醍醐味＝Studioの真骨頂）
で、如何に
変数名と引数名の取り扱いが
Studio開発のカギを握るか
動けばいいや、自分のやり方は違う
で、可読性も変更可能性も意識せずに、変数名と引数名を漫然と意識もせずに、語彙力もなくやり取りしてると
如何に危険で管理しにくくするか
が分かると思う( ´∀｀ )
さらにもう一歩前へ：変数の初期値を入力する箇所
で、ここが今回の最後なんだけど、ここまでのソースではオイラは、
変数：代入アクティビティで初期値を設定
引数：変数の代入結果をそのまま代入
て感じにしてたんだけど、勘のいい人はお気づきだと思うけど、UiPath Studioは値を代入する方法として、
それから、今回示した
の３つがあるんだけど、
何故前者２つは使わないのか👀❓
必ずそうしないといけないって訳ではないんだけど、
【理由】
「ある値は、引数のインポートの中」、「別の値は、変数や引数の定義エリアで規定の値を設定」、「そのまた別の値は代入アクティビティで」、、、と統一性がない書き方をすると、他の人はおろか数か月後の自分ですら見落とす危険がある☞不規則なモノは必ず見落とす危険がある
ハードコーディングの禁止で、値は極力直打ちしない方がいい。☞Configファイルで極力管理。
引数のインポートや変数や引数の定義エリアの既定を設定すると、初期値を設定してるのと変わらないので、繰り返しの中で使った場合、繰り返しの度に、最初の処理で値が上書きされてしまい、想定した処理結果にならない危険あり。
だから。どうせ初期値を設定だけするなら、編集エリアで明確に
処理の最初に
①何の値が
②どこから入ったか
が把握しやすいでしょ
☞管理や確認コストの軽減( ´∀｀ )
さらに引数は、この記事の冒頭で説明したとおり、
引数＝あくまでも、値を引き渡す（やり取り）するだけのもの
☞引数に直接、値を書かない。
＝変数を使った最終処理結果なんかを代入するだけ
で統一しておく。
これを意識してない自称さんほど、
変数も引数もお構いなしに、どんどんいろんな箇所に統一性もなく、直で既定値を設定して、改修コストもかさんで、ドツボにハマってるんだよねえ( ´∀｀ )
元凶としては、
UiPathの基礎コースでの例示
Re-Frameworkテンプレート
Frameworkて意味
なんかを
自分で突き詰めてよく考えずに、
漫然と素通りしちゃって
Re-Frameworkで引数をインポートのValueに値を直書きしてるからそのままやってしまう→やっていいいし、UiPath が提供してるモノがそーだからこれが正しいと思い込む
Frameworkて部品を少しでも変更したら壊れるって勘違い☞Frameworkって意味わかってんのか( ´∀｀ )
が開発現場では多いんだけどね( ´∀｀ )本当に、
Re-Frameworkテンプレートがそうしてるからってそれしかしちゃいけない
UiPath から提供されたFramework部品を一切変更しちゃいけない
なら、
UiPath Studio自体が
融通が利かないものになって、
業務に合わせた開発の限界とか障壁が多くなる
☞百害あって一利なし
んなこと、
民主化されたテクノロジーを提供してる会社がやるわけないでしょ( ´∀｀ )
それを触って壊れるのは、
改修方法を知らないか誤っているだけが殆ど。
必要に応じて、適宜、改修を加えられないソースを
テンプレートとかフレームワーク＝ひな型
とは言わない
逆に、正直ゆーて、
自分がやりたい処理のアクティビティを組めて、共通する部品を自分で再利用する方法を知ってるなら、別にそんなもん一切使う必要ないんだけどね( ´∀｀ )
今回の内容としては以上かな( ´∀｀ )
さてと、最後に
ソース・リファクタリング（まとめ）
■Main
■RobotMain
■ReadConfig
とまあ、裏を返すと、処理としては一見こんなに
簡単でシンプルな処理しかしてないんだけど、きちんと普段意識しておかないといけないことを説明しようとすると、実は基本的なことだけでもこんだけの分量になるくらい、
すっげえ重要
ってことをイメージしてもらえば十分
さてと、次回は
Configファイルの読み込みXamlの追加まで今回できたので、いよいよ、
Configファイルの読み込み処理のために
必要なアクティビティを組み込んでく( ´∀｀ )
これもいくつかの記事に分けて順を追って説明してけど、ひと言に、
Configファイルを読み込む
てゆーても、きちんと順を追っていくと、
Configファイルの格納フォルダを確認
Configファイルの存在を確認
Configファイル内のシート存在確認
ってな感じで前回示した構成要素がいくつかの単位に分かれるので～他のロボットにも使える共通的な処理ワークフローファイルを格納して、活用する
ライブラリフォルダを用意
に触れながら、各処理をひとつずつ組み込んでく( ´∀｀ )