これは、UiPath Friends アドベンターカレンダー2020 の23日目の投稿です
#はじめに
（ほとんどの人は）はじめまして。TwToshiyaと申します。
UiPath Friends アドベンターカレンダー2020に参加しています。
本当は前回同様いくつかMarketplaceにあるアクテビティで、名前だけ見るといろいろ使いそうなものが出てきたので、検証がてら紹介しようと思ったんですが、検証がまにあわず、断念しました。
なので、ガラッと趣向を変えて、手持ちのナレッジだけで説明できる簡単な開発論を紹介したいと思います。
皆さん、「構造化プログラミング」って知っていますか？
たぶん、40歳以上でCOBOLとかPL/Iやってた人はご存じだと思います。
前処理、主処理、後処理‥
最近めっきり聞かなくなりました。
そんな昔の考え方ですが、「今はやりのRPAで生かせるかもしれない！」 そんなお話です。
#構造化プログラミングとは
構造化プログラムそのものは、1968年にエドガー・ダイクストラが「Go To Statement Considered Harmful」で言及したのが最初とされています（Wikipwdiaより）諸説あり
当時COBOLやFORTRANなどの高級言語で多用されていたGOTO文による制御が主流であり、極端に可読性が落ちていました。分岐が発生した瞬間、分岐した起点から再度追跡を開始しなければならず、また中間点から中間点にジャンプする場合もありソースコードの追跡も非常に困難になっていました 1 。１ページに納まるソースコードなら何とか追い切れるかもしれませんが、500ステップ（行のことです）を超えた日にゃ💦 2 そこでエドガーさんは、プログラミングは『頭に一つの入口を持ち尻尾に一つの出口』という逐次プログラミングに限定し、その中で「分岐」「反復」をもちいてプログラムを記述できないかと研究し、発表しました。
その後、IBMのハーラン・ミルズ等によりフローの詳細化の分割（ネスト）や、機能を一塊にして管理しやすくしたブロック化、共通機能をひとまとめにして外部化して必要な時に呼び出される「サブルーチン」など、記述の構造化に関する事項が追加され、また、いろいろなソフトウェアベンダーで構造化プログラム（階層化プログラムともいわれていました）をベースとした開発技法が研究され、効率かどうか数学的な検証もされつつ、業務プログラムの基礎となりました。
しかしながら、これは当時主流だったバッチプログラム（オンラインもボタンを押して画面から小さなバッチプログラムが起動する仕組みでした）を対象としたものであり、また、処理の流れも一定になることを強制しているため、WindowsやWeb系の開発など、インタラクティブかつ多種多様な画面構成を持つアプリケーションの開発が増えてくると、だんだんとあまり実際の開発実態と会わなくなりました。
さらに、本パラダイムはあくまでも処理が対象であり、データと処理を合わせて考える「オブジェクト指向」が実用段階になると、プログラム技法の議論がオブジェクト指向に移るようになり、構造化プログラムということば自体が語られなくなってしまいました。
しかしながら、基本理念（逐次、分岐、反復）は様々な言語仕様に取り込まれ、最近の高級言語では、どの言語を使用しても、たいてい構造化プログラミングで定義された記述になるようになるなど、その影響力の大きさがうかがえます。
#UiPathでも適用できるところ
構造化プログラミングが華やかなりし２０世紀末、アプリケーションベンダーやシステムを開発していた企業（主に金融機関など）は、盛んに構造化プログラミングに独自に以下のルールを取り入れた開発技法や表記法、それを取り入れた社内規約を作っていました。
UiPathでも取り上げることが可能な部分を上げてみます
- 処理を １）初期処理 ２）主処理 ３）終了処理 の ３つに分ける
プログラム(ワークフロー)を大きく３つに分け、それぞれやることをある程度決めておく。特に初期処理／終了処理は、処理パラメータの取得（初期処理）、開始・終了メッセージ出力、処理件数出力など、やることをある程度全体（チーム、もしくは会社）決めておくことで、処理の抜けをなくす効果はあると思います。
特に開始／終了のログ出力や件数表示などは漏れが出やすいところなので、ルールとして決めておくといいと思います
- 処理を意味のあるブロックにまとめて記述する（たとえ反復がなくても）（セクション、またはコードブロック）
→似たような処理はコードブロックやセクションにまとめて管理しましょう
シーケンスを使ってグルーピングするとわかりやすくなりと思います
たとえば、Excelからデータを取得する部分を１セクション、そのデータを受けてWebから検索する処理を１セクション等に分割すれば、仮に変更があった場合、どこに手を入れればわかりやすくなります。
※インターフェイスがうまく定義できれば、ワークフロー分割でXAMLファイルを機能単位で分割し、分業開発ができるかもしれません
- 終了ポイントが一カ所になるように記述する
→ これは、かならず固定のポイントで終わる（たどりつく）ように癖をつけましょう
どこで終わるかかがわかっていると、何かあった時逆からのトレースがしやすくなります。
（たまに分岐でとんだ先の終了がばらばらという処理を見ることがあります）
- 共通化できる処理はなるべくひとまとめにして再利用する（サブルーチン）
→ ライブラリ化やワークフローの分割で実施ます。残念ながら、同一ワークフロー内の処理を再利用する方法はなかったと思います。ここだけがUiPathの弱点ですね。（あったら（できたら）訂正します）
ちなみにUiPathから出ている「ReFramework」もある程度上記考えて作られているようです（半ばこじつけ）
※フローチャートのレイアウト固定機能がステートマシンに適用されていないので、配置がちょっとあれですが。
#最後に
この記事を書くために「構造化プログラム」というキーワードで検索したんですが、意外とヒットしなくて愕然としました。たしかに、スマホやWeb系のアプリ開発など、画面単位でかつ、どこから始まるかわからないようなアプリの開発にはなじまないかもしれません。
逆にRPAの処理は昔よくあった「バッチ処理」に近く、比較的親和性が高いかもしれません。UiPathに限らず、他のフローチャートとで記述できるRPAツールでも適用できる考え方だと思いますので、ご参考になれば幸いです。
ご拝読ありがとうございました