Blue Prismベストプラクティス 番外編 4 開発規約・コーディングスタンダード
見出し画像

Blue Prismベストプラクティス 番外編 4 開発規約・コーディングスタンダード

Blue Prism 公式 note

どもども、ジャナイホーです。

みなさま、開発規約って作ってます?
業務の自動化を推し進めていくうえで、かなり有効な手段となり得ます。

今回は、少し、開発規約にはどんな情報を盛り込むべきか、ジャナイホーなりの考えをもとに、規約項目をリストアップしてみようと思います。

、、、読んだよ。
分かったけど、じゃぁ、具体的に次にどうすりゃいいの、と疑問をお持ちの方。他の人が作ったロボットを見てげろ吐きそうな思いに駆られている方。CoEチーム作りに悩んでいる方。
検討の参考にしてみて下さい。

開発規約に盛り込みたいこと

例えば、下記のようなものを盛り込んでおくと、成果物が均質化されるのでは、と思います。

オブジェクト開発

  • 一つのオブジェクトは、一つの画面ごとに分割して作成すること

  • 一つのオブジェクトアクションページは、一つの操作ごとに分割して作成すること

  • 一つのオブジェクトアクションページ内では、ステージの数は○○以下にすること

  • 一つのオブジェクトアクションページ内で複数の操作を行わないこと

  • 一つのオブジェクト内のアクションページの数は○○以下にすること

  • オブジェクトには、業務判断などロジックを実装しないこと

  • グローバル変数はInitailse/初期化ページへ記載すること

  • 共通のアタッチ処理を使うようにすること

  • ステージのInputやパラメータ値はハードコードせずにデータアイテムを利用すること

  • 無条件Wait、スリープは、原則利用禁止

  • アクションページでは、冒頭に、必ずアタッチページとその後に存在確認を含むWaitステージを入れること

  • 画面遷移後、あるいは操作後に、もしくは画面に変化が発生する場合は、必ず存在確認を含むWaitステージを入れること

  • 特定のフィールド操作(読み込み、書き込み、ボタンクリックなど)存在確認を含むWaitステージを入れること

  • オブジェクトアクション内で、公開済みの他のアクションページを呼び出さないこと

  • オブジェクトアクション内でのデータアイテムの初期値の設定は回避する(パラメータでプロセス側から値が渡ってくる実装にする)こと

  • オブジェクトアクション内にException Handlingを入れないこと。オブジェクトでは例外をスローするだけにすること。

  • 極力Global系の操作は行わずに、Pressや書き込みステージなどを優先すること

  • システムエラーかビジネスエラーかを明確に上位に伝達すること

  • エラー発生時の画面スクリーンショットの保存をオンにすること

  • Terminateの操作ステージは極力回避し、正しくログアウト、終了するメニューを利用すること

  • Global系の前にActivate Applicationなどを入れること

  • 文字入力、操作の間隔(0.1秒、0.5秒など)を入れること

  • コードステージを利用した、カスタムコードによる実装は極力回避すること。どうしても必要な場合の作成判断基準は○○とする

  • ラッパーオブジェクトの作成判断基準は○○とする

オブジェクト開発 - スパイとアプリケーション モデラー

  • Spyモードの選択は、Win32/HTML⇒UIA⇒AA⇒Regionという優先度で試行すること

  • Application Modellerでの属性選択は、不要なもの、○○は外すこと。○○を入れること

  • Application ModellerでのElement構成は、画面単位で階層構造とすること。命名規則に準拠すること

  • 複数のSpyモードで実装するときは、属性名にモードを含めること

  • パスワードを入力する際は、パスワード属性タイプ、パスワード型を利用すること

プロセス開発

  • テンプレートを利用して開発(ワークキュー利用を徹底)すること

  • ○○のエラーの場合は、○○でエラー通知すること

  • Mark Exceptionにて、○○の場合はリトライすること。○○の場合はリトライしないこと

  • プロセスをTerminateするのは、○○のケースとすること。Exception発生した際に通常フローやEndに接続し、正常終了(ステータスがCompleted)にならないようにすること

  • ステージのInputやアクションへのパラメータ値はハードコードせずにデータアイテムを利用すること

  • システムエラーはリトライし、ビジネスエラーはリトライせずに次の処理に進むようにエラーハンドリングすること

  • プロセス、プロセスのメインページ、サブページ、オブジェクト、オブジェクトアクションページのそれぞれの役割分担を明確にすること

プロセス開発 - サブページ

  • ひとつのサブページ内に記載するステージの数は○○以下にすること

  • プロセススタジオを全画面表示し、100%ズームの状態ですべての処理が可視範囲内に収まるように、1つのページの処理を収めること。すべて見切れないページの場合は、処理が複雑すぎるので、サブページに分割し、視認性、メンテナンス性を確保すること。

  • サブプロセス、他のプロセスの呼び出しは禁止とする

  • エラー発生時の回復機能の実装を徹底すること

  • リトライの基準、無限ループの回避(システムエラー、データエラーなど)

  • 複数の似たような処理を実行する場合は、サブページ化するなどして共通化すること

  • サブページでは、Recovery→Resume後、正常終了Endに吸収しないこと。必ず例外をスローして、エラーを上位ページに戻すこと

  • リトライループはサブページで実装すること(オブジェクトやプロセスのメインページでは実装しないこと)

プロセス開発 - ワークキュー

  • 入力ファイル読み込み時、環境ロックを使った排他制御処理を実装すること

  • 同じファイルを重複して読み込まないように、読み込みとワークキューへの書き込みが完了したファイルは、別フォルダへ退避すること

  • 繰り返しループを使うものは極力ワークキューでの実装すること

  • ワークキューアイテムのグループ分けをする為に、Tagを活用すること

  • ワークキューをキューアイテムのループ以外の目的で利用しないこと。オブジェクトでワークキューを利用しないこと

  • コントロールルームから制御できるように、テンプレートにある「IsStopRequested()」の仕組みを実装すること

エラーハンドリング全般

  • リカバリーモードでのロジックの実装の禁止

  • ブロックを細かく使うこと。ブロックなしのエラーハンドリングは実装しないこと

  • Exception Typeの定義は、○○と○○を利用すること。勝手にException Typeを作り出さないこと

  • Exception Detailに記載する内容は○○とし、ユニークなエラー番号を記載し、特定しやすくすること

  • オブジェクトアクション内にException Handlingを入れないこと

  • オブジェクトやサブページは、システムエラーかビジネスエラーかをException Typeにて明確に上位にスローすること

  • エラー発生時の画面スクリーンショットの保存をオンにすること

ロギングの基準

  • ループを繰り返すような処理の中やオブジェクトでは、極力ロギング設定をオフあるいはエラーのみとすること

  • Start、Endのステージでのロギング設定は○○とすること

  • オブジェクトのロギング設定は○○とすること

  • コレクション、センシティブなデータのパラメータ利用のロギング設定は○○とすること

データの扱い

  • URL、フォルダパス、Wait時間など、環境に依って違う値になるものについては、環境変数を利用すること

  • ユーザアカウント、パスワードなどの認証情報は、認証マネージャから取得すること

  • センシティブな情報を扱う場合は、パスワード型を利用すること

  • センシティブな情報を扱う場合は、ロギング設定をオフにすること

その他

以下を定義やルールを遵守すること

  • 命名規則

  • ブロックの色選択基準

  • インプットファイル、アウトプットファイルのフォルダ構成

  • 送信メール、受信メールの記載ルール

  • 利用言語

  • ログ出力書式

  • Descriptionに説明文を記載する基準

  • 開発手順(オブジェクト作成⇒プロセス構築、コントロールルームでのテスト実行)

  • 開発者の前提トレーニング(ワークキューとException Handlingの文書、など)

  • 開発完了後の手順(Build Review Check Listを参照し、開発したオブジェクトがベストプラクティスに則っているか確認する、など)

まとめ

意外とありますな。。。

最初のうちはこれを全部守って開発すると、時間もかかるとは思いますが、慣れれば、、、大丈夫、のはず。
少なくとも、これをレビュー担当者はレビューチェックポイントリストとして活用頂くこともできるかと思います。ベストプラクティスが盛り込まれます。

しっかりと開発規約・コーディングスタンダード文書を定義しておけば、なにより、設計書を書く、という運用にしている場合、設計書に書く内容をかなり省くことが出来るはずです。共通認識なので。

※本投稿は、別ブログで掲載・公開していた内容に加筆・修正を加え再掲載しています。

みんなにも読んでほしいですか?

オススメした記事はフォロワーのタイムラインに表示されます!

©2022 “Blue Prism”, “Blue Prism”のロゴ、ならびにPrism製品はBlue Prism Limitedの商標または登録商標です。​Blue Prismの著作物である旨明示いただければ、複製、転載を許諾します。

うれしいです
Blue Prism 公式 note
Blue Prism株式会社のnoteアカウントです。Blue Prism株式会社のメンバーが、製品の技術的な解説や活用Tipsなど、業務プロセスの自動化やDXに役立つ情報を投稿していきます。時に担当者の個人的な見解も含みます。© 2022 Blue Prism.