以前に「UiPathシナリオワークフロー研究会」というものがあり、そこでLTした内容をちょっと修正しました。
※これらはあくまで個人の見解です。
Flowchart（フローチャート）を極力使わない
フローチャート自体は大変便利な機能です。ワークフローの流れが一見してわかりやすいし、もともとフローチャートで書かれたドキュメントなどがあればそれを踏襲して開発することで、比較・確認しやすいワークフローになります。
ただし、新規で開発をするのであれば基本的にはSequence（シーケンス）を第一選択とすべきと、私は考えます。以下に理由をいくつか記します。
- フローチャートに配置されたアクティビティ（シーケンスを含む）は、そのアクティビティの「開発ペイン上に表示される」設定項目が表示されません。
- 表示するためにはクリックして右側のプロパティ画面を見るか、ダブルクリックしてアクティビティの詳細を表示しなければなりません。
- ダブルクリックして表示した場合、もとのフローチャートに戻るためには、開発ペインの上部にあるパンくずリストを用いる必要があります。
- アクティビティの配置（位置や接続）を意識する必要があります。
- 特に配置については、個々人での美学に依るところがあります。何かしらのルールがあれば良いかもしれませんが、そうでなければワークフロー内がいわゆるスパゲティ状態になる可能性が高いように思います。
- そもそも、フローチャートでないと実装できないようなプロセスがそれほど多くないように思います。
- 例えばループ処理を実装する中で、「A→B→C→D→E」と進むプロセスが存在して、CやDで何かしらループを戻る処理を、「CのときにはB」「DのときにはA」という要件に基づいて実装したい場合、これはフローチャートでないと実装できないです。少なくとも For each のループにおける Continue では、前述の例でいうと A にしか戻れないからです。
- 逆を返すと、上記のような要件が生じるようなプロセスが現状どれほどあるか、に尽きるかと思います。これまでにビジネスにおいて開発した経験では、上記のようなプロセスのタイミングに依る戻り先の変更の要件はありませんでした。
変数名に型の名称を含めない
変数を命名するときに、プレフィックスやサフィックスとして、変数の型を表す文字列 （ex. str）をつけるケースを良く見ます。これを「システムハンガリアン」と言います。この記法は、ケース・バイ・ケースではありますが原則としては採用する必要は無いと考えています。
- この記法の意義のひとつである「変数の意味」が、「型」に含まれるため。
- プログラミング言語においては「型」という概念を含まないものが存在し、そのようなプログラミング言語による開発においては、変数名に、変数に含まれると想定されるデータ型を記載することに意義がありました。しかしながら、UiPath のバックエンドである .NET Framework ないし C# では、この「型」が概念に含まれているため変数名に記載する意義が存在しません。
- .NET Framework において、この記法を禁止しているため。
- この記法を使用したことに依るペナルティなどが存在するわけではありませんが、少なくともこのフレームワークを開発した Microsoft の公式ドキュメントにおいては、上記の通りこの記法を DO NOT （すべきではない） と表現しています。
- 変数名を無用に長くしてしまい、その意味を読み取ることを困難にするため。
- これは悲しいことではありますが、UiPath Studio においては変数名などのパラメーターを設定する画面のサイズが十分ではないケースが多々あります。その貴重なスペースをプレフィックスを表示するために利用してしまうと、その先にある「意味」を表すべき文字列が表示されず、可読性を下げてしまう結果となります。
（以降、追記作業中。。。）