Blue Prismベストプラクティス 番外編 4 開発規約・コーディングスタンダード
どもども、ジャナイホーです。
みなさま、開発規約って作ってます？
業務の自動化を推し進めていくうえで、かなり有効な手段となり得ます。
今回は、少し、開発規約にはどんな情報を盛り込むべきか、ジャナイホーなりの考えをもとに、規約項目をリストアップしてみようと思います。
、、、読んだよ。
分かったけど、じゃぁ、具体的に次にどうすりゃいいの、と疑問をお持ちの方。他の人が作ったロボットを見てげろ吐きそうな思いに駆られている方。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を参照し、開発したオブジェクトがベストプラクティスに則っているか確認する、など）
まとめ
意外とありますな。。。
最初のうちはこれを全部守って開発すると、時間もかかるとは思いますが、慣れれば、、、大丈夫、のはず。
少なくとも、これをレビュー担当者はレビューチェックポイントリストとして活用頂くこともできるかと思います。ベストプラクティスが盛り込まれます。
しっかりと開発規約・コーディングスタンダード文書を定義しておけば、なにより、設計書を書く、という運用にしている場合、設計書に書く内容をかなり省くことが出来るはずです。共通認識なので。
※本投稿は、別ブログで掲載・公開していた内容に加筆・修正を加え再掲載しています。