見出し画像

【いきなりStudio24】（実践編）［UiPath✖YouTube］セレクターを含めたConfigファイルへの外出しでガチろう～ロボパ、タイパ、コスパまで意識してセレクターまで外出しするのが、ガチラーの基本中の基本( ´∀｀ )。

M_Kaku堂

さてと、前回

で、

ブラウザにアタッチ

まではやったので、今回は前回の最後で予告したとおり、

前回組んだ正常系ソースのリファクタリング
👉セレクターまで含んだ、
Configファイルへの外出し

についてやってく💃
んだば早速

前回の続きからソース・リファクタリング

※ちょいと記事を複製したら、スクショ画像が綺麗に消えてしまった👀💦
複製したらスクショ画像が消えますって事前に書いとけよnoteさんよ( ´∀｀ )

前々回、説明が薄くなったのもあるので、まあ外出しの手法も含めて～～まずは、

■リファクタリング前

前回の最後のソースからアクティビティの名前変更と注釈を入れたところ

複製したら消えちゃったんでスマソ( ；∀；)

ここでポイント①：現在、ハードコーディングになっているので、Configファイルに外出ししてく手順を詳細に( ´∀｀ )

直打ちになっている箇所としては、

①アタッチのセレクター

これを

前々回、アプリケーションを開くで
使ったアクティビティと同じものを使うので、
ここは普通は外出し不要

なぜかと言うと、

同じ値なのに別のキーで追加すると
管理が煩雑になる
👉オイラならやらない

まあ、別に、それでも分けたいなら

こっちの方がイメージ湧きやすいだろうから、
今回は、やっておこうか( ´∀｀ )

てな感じ

で、今追加したキーを

＋マークをクリック
詳細エディターを開くをクリック
てな感じになっているのを
ReadYouTubeConfig("Edgeにアタッチ").ToString
てな感じで指定して、OKをクリック
てな感じ

②アドレスバーに文字を入力

セレクターとテキストを同様に変更👀💦

コイツな

セレクターは同じ要領で

セレクターシートにキーを追加して、
値にセレクターを追記＝外出し

で、編集

ReadYouTubeConfig("Edgeアドレスと検索バー").ToString
てな感じでOKをクリック
てな感じ

で次にテキストなんだけど、これは実は既に

てな感じで存在してるの～～～
ReadYouTubeConfig("YouTube").ToString

を、

てな感じでOKをクリック
ホイ、出来た( ´∀｀ )
てな感じ( ´∀｀ )

③アドレスバーでEnterキー

ココな

ここはUIExplorerで開くと、

②と全く同じセレクターなので～～～

コイツはセレクターのみを変更しておく

てな感じでOKをクリック
てな感じ

編集後に問題がないかもう一回、ファイルをデバッグで実行してみる

Configファイルは上書き保存して、閉じた後、Main.xamlに戻って、ファイルをデバッグをクリック。

コイツな

ちょっと、前回のOpen_Edgeの

Edge検索バーキーでエラーが起きたので、

Edgeアドレスと検索バーと同じセレクターに値を貼り替え

👉変えるのはキーではなく、値

で再実行すると、

ホイ、問題なし( ´∀｀ )

もう一歩前へ：UiPathの開発で一番意味のない作業👉机上デバッグ

さてと、ここでちょうどいいので、日本企業の殆どが毒されている

過剰なまでの品質意識

で、どこの現場でもよくやるのが

机上デバッグ：ソースやコードだけを査読して、バグがないかを確認する
（JSTQBの工程で言えば、
ホワイトボックステストの技法）

なんだけど、UiPathをよく分かっていない開発現場ほど、他の開発と同じで、

開発のステップで机上デバッグをやる
↓
品質がよくなり、開発者の育成にもなる

と妄信して、

開発工程に当たり前に
織り込もうとし過ぎ( ´∀｀ )

なぜ、UiPathの開発工程で机上デバッグが殆ど意味がないのか❓👀理由はめちゃくちゃ簡単で、

UiPathの醍醐味＝セレクターを介して、
直接WEB上の操作が出来る
👉他の会社のサービス（ここで言えばEdge）
が絡む

から( ´∀｀ )
つまり、Microsoftが作って公開してるEdgeってサービス自体を自分の会社で作っていないのに、Microsoftが勝手にEdge上のセレクターの要素を変えた場合、

いくらワイルドカードで、今後変更される箇所を想定して、セレクターの一部を変更しても、今みたいに、必ずエラーにならないとは限らない( ´∀｀ )
👉コードやソース上は完璧でも、エラーになる可能性あり。
↓
いくらタグまで含めて、机上デバッグを繰り返したところで、Microsoft側がEdgeのタグを変更しちゃえば、エラーになる可能性が高い

👉机上デバッグをしたところで時間の無駄

無駄な机上デバッグなんざやらずに、

この記事でやってるセレクターを外出しして、パブリッシュせずに変更出来る技法と、次回やる、エラーハンドリングなんかで、
セレクターが取得できないなら、安全にコカして、変わった後のセレクターにConfigファイルを書きなおす方が手間や作業コスト、管理コストもかからず安全
だから( ´∀｀ )

机上デバックが必要かいなかの切り分け方は、単純に

  • 机上デバッグが必要：全て自社開発のサービスだけでやる製品

  • 机上デバッグが不要：他の会社で作ってるサービスが絡む製品

てだけ。Microsoftはじめ、GoogleにしろAppleにしろ、別にブラウザを開発してる他社のエンジニアが、このサービスを使って、ユーザーがUiPathでロボットを開発してるなんて知ったこっちゃないし、そんな自分ところが作ってないロボットを気にして、一切タグなんかを変更できないってなると、、、

Microsoft側で、Edgeの改修とかアップデート
なんて何ひとつ出来ない

ことになるからね( ´∀｀ )

これをよく理解してない人や組織が、プロジェクト管理で妄信して、UiPathの工程でも

  • 机上デバッグ

  • 単体テスト（これも要らない。どうせ動かしながらインクリメンタルに組み込んでいくから）

するのが当たり前なんてゆーてるから、そーゆー人を見たら、

この人、レガシー（化石時代）で止まってる
エンジニアさんだ👀未だにいるんだ💦
アンモナイトを発見した感じで
崇めてあげましょう( ´∀｀ )

なんかでも書いた

コンストラクション

を、熱っぽく手でろくろを回しながら、建築なんかに例える人が多いんだけど、それが通用するのはあくまでも、

全てのサービスが自社開発のサービスのみで完結
しかも、
全サービスの開発部門と密に連携が取れている場合だけ( ´∀｀ )

ここでポイント②：セレクターまでConfigファイルに出すメリットは👀❓可読性が落ちるから、セレクターはそのままの方が良くない

ってどこの現場に行っても、強硬に反対してくる人がいるんだけど、セレクターシート見てみると、

編集後のセレクターシート

メリットとしては、

  1. オイラがUiPathStudioXの記事のときから、ロボットで使ってるセレクターが一元管理出来る👉システムとかWEBサイト側で変更が入った場合の変更箇所を一覧で俯瞰できる

  2. さっきのアドレスバーのところなんて全く同じセレクターをConfig引数で同じキーの値を指定しただけ👉複数箇所で同じセレクターを使う場合、改修が楽

  3. さっきみたいに、もし似通ったセレクターを値に持つキーでどちらかがEdge側の変更で上手くセレクターが取得できずにエラーになった場合、そのキーの値を別のキーの値に変更するだけで、セレクターを変更できる👉再度、パブリッシュし直す必要がない

一歩前へ：リファクタリングって言葉がどの学校や職場でも

当たり前の作法

として定着してきてるみたいなんだけど、今までやらなかったのを

リファクタリング：コードとかソースを安全に動かす技術
👉よく使う機能や処理は単体で小分けにして繋ぐ

みたいな、

なんかで紹介した、マーティンファウラーが20年くらい前に提唱した

リファクタリングの基本＝小分け管理

だけやって、.xamlファイルを前回紹介したみたいにミクロ単位で同じようなセレクターを使ってる機能を小分けにして、ワークフローとして抽出してまくって、その.xamlファイルが30個も40個も小分けにしてたら、

セレクターの箇所に改修入ったときに、
地獄じゃね( ´∀｀ )
👉変更箇所が直打ちしてるばかりに
ファイル数分ある
ってことになりかねないからね( ´∀｀ )

「そんなときは、ユニバーサル検索で変更すべきセレクターを確認すればいい」って人も居るんだけど、

コイツな

  • 人の手で数十カ所の変更をかけたら、ミスも起きやすいし、

  • 仮に全て変更出来たとしても、変更後再度パブリッシュが必要( ´∀｀ )

そんなときに、

セレクターまでパラメータ化して、
Configファイルで一元管理
👉変更が入れば、
そこのキーの値だけ変更すればいい。
パブリッシュも要らない

てしておくのと、どっちの方が、

安全に変更出来て、管理しやすいか

って話( ´∀｀ )

リファクタリングをするなら
その副作用を最初から意識する
のも当たり前の作法( ´∀｀ )

ここでポイント③：リファクタリングの副作用

パッと今思いつくだけでも、

  1. 管理対象のファイルが増える

  2. 全て小分けにした結果、逆に処理速度が遅くなり、時間が数倍に跳ね上がる

  3. 引数の受け渡しで参照型の値を繰り返しの中で小分けにしてしまい、入力しかしないはずなのに、入力元の値まで上書きされてしまう

などなど。例えば、
「全部で10000回繰り返す、繰り返し処理の中で行う処理まで、小分けにし、１回の処理あたり１秒以上、余計な時間がかかるようになってしまい、処理全体で10000秒（＝3時間）余計な時間がかかるようになってしまった。」
なんてのはよくある話( ´∀｀ )なので、

リファクタリングをやる際には、
コードチューニングをセットで、
処理時間＝ロボパのバランスを取るの
も基本中の基本

ここでポイント④：Configファイルに外出ししたときによくやらかすエラー👉重複キーエラー

語彙力のない人で、キーの名前を

下ふたつが重複してる

で、やらかしちゃう人も居るんだけど、環境設定とか読み込み方によっては、
辞書＝ディクショナリ型でキーの値を読み込んでいるから、名前が重複するキーがあると、どっちの値を取っていいか分からない

👉結果、実行中にエラーになっちゃうんで
気を付けてね( ´∀｀ )

普通に人間が使う辞書でも、

ひとつのキーワードに複数の意味が書いていて、同じキーワードが

春：３～５月くらいの季節。梅雨に入る前。
春：四季の名称のひとつ。
春：一生で一番栄えた時期の始まりを指す。
春：新年。立春

みたいな感じで羅列されてないでしょ( ´∀｀ )
春なら、
春：①３～５月くらいの季節。梅雨に入る前。②四季の名称のひとつ。③一生で一番栄えた時期の始まりを指す。④新年。立春。
てな感じになってるはず。

■リファクタリング後

てな感じ

（前回と今回の）まとめ：要は、

  1. PPPでやる処理を人間の言葉で書き出す。

  2. ソースを組み込み終わってすぐに検証する。

  3. 検証後セレクターも含めて、Configファイルに外出しする

は、

安全にロボットを管理する
＝ガチりの基本中の基本
👉標準的なロボットエンジニアなら現場で
誰もが普通にやってる作法

なんで、何かの参考になれば幸い( ´∀｀ )

さてと、次回は

今回やった正常系にエラーハンドリングまで加味して肉付けしてく実践編のソースの組み込み方をやってく💃

次回使うアクティビティで特に大事なのは、

繰り返し回数アクティビティ

んだば、また次回( ´∀｀ )

※ちょっと、複製後にいったんスクショが消えたので、一応つながるように張り替えたけど、何か不備があるのに気づいたら、明日以降でシレっと直しとくや( ´∀｀ )
公開前に見返したから多分大丈夫だとは思うけど👀( ；∀；)

noteめ(# ﾟДﾟ)
いつもお世話になっております( ´∀｀ )

いいなと思ったら応援しよう！