DataSpiderデザインパターンβ 第1回 スクリプトパターン「Script Guideline」

Avatar
dstn


 

今回は、スクリプト開発の前提となるガイドラインを作成するパターン「Script Guideline」パターンを実際の例を見ながら解説していきます。これは、今後のスクリプトのパターンを考える上で前提となるパターンとなります。

 

1 課題


DataSpiderのスクリプトは、コンポーネントのレイアウトや処理順序などを開発者が自由に設計できるようになっている。これにより、さまざまな要件に対応するスクリプトを作成することができる反面、設計の統一性がとれず、結果的に以下のような問題が発生し、品質や生産効率、保守性に問題が生じることがある。
・スクリプトを後から他の開発者が修正しようとしたが、処理の内容が複雑過ぎて修正できない
・定型的なビジネスロジックを各スクリプトで実装していたため、変更になった場合に多数のスクリプトの修正が必要
・1つのスクリプトで非常に多くのコンポーネントアイコンを使用しているため、プロジェクトの保存やスクリプトのロードに時間がかかる
・スクリプト間でデータを受け渡す際、データスキーマに整合性が無い

これは、開発期間が長期化したり、また開発者が多く関わっていた場合より顕著になる。

 

2 解決方法


DataSpiderを使用した開発の前に、開発標準となるガイドラインを作成し、開発者に周知する。また、レビューの機会を設けてガイドラインの遵守を徹底する。

 

3 説明


DataSpider 3.0のヘルプ「サービスガイド」-「サービスの開発」の中で、以下の項目について標準となる方針を決定することを推奨している。
まずは下記の項目についてガイドラインを作成し、事前に開発者に周知した上でスクリプト開発を行うことが望ましい。




■プロジェクトやスクリプトの構成
・プロジェクトの処理単位
・スクリプトの処理分割単位
・プロジェクト間およびスクリプト間の値の受け渡し方法
・1スクリプト内のコンポーネントアイコン数

■開発および本番環境
・開発および本番稼働の実行時のログレベル
・開発および本番稼働時に使用するグローバルリソースの種別

■ファイルの保管場所
・読み込みおよび書き込みを行うファイルの保管場所

■命名規約
・プロジェクト名
・環境変数名
・スクリプト名
・スクリプト変数名
・コンポーネント名
・グローバルリソース名
・サービス名
・トリガー名




また、適宜レビューの機会を設け、ガイドラインに沿っていないものは無いかをチェックすることによって、より成果物の品質が高まる。これは開発の最終段階はもちろん、まだ開発者にガイドライン遵守の意識が浸透していない開発初期においてはより必要となる。

pattern1

4 メリット


・1つのスクリプトで行われている処理が分かりやすくなり、保守性が向上する
・プロジェクト・スクリプトのロード時間が短くなるため、開発効率が上がる
・保管場所を定める際にスクリプトで使用しているファイルが集中管理されるため、複数のプロジェクトをまたいでのファイルの管理がやりやすく、サーバの移行作業もやりやすい

5 注意点


・開発しようとする連携システムの要件や開発規模によって、事前に決定しなければならない項目や具体的な内容は異なる。上記以外の項目についても規約を定めておいた方がいい場合や、あえてDataSpiderの機能を使わないことによってメンテナンス性を高めることも考えられる。

そのため、汎用的なガイドラインを具体的に提示するのは難しい。

以下では一例として、アプレッソのQAチームが、DataSpiderのコンポーネントのテスト用のスクリプト開発において用いているガイドラインを紹介する。



プロジェクトやスクリプトの構成


・プロジェクトの処理単位
- コンポーネント単位とする。

・スクリプトの処理分割単位
- 機能単位とする。

・プロジェクト間およびスクリプト間の値の受け渡し方法
- 入出力スクリプト変数を使用する。

・1スクリプト内のコンポーネントアイコン数
- メンテナンス効率を上げるため、基本 10 個以内とする
- 多くても 25 個までとする (推奨最大数の1/4)

開発および本番環境


・開発および本番稼働の実行時のログレベル
- 基本はINFO。ただし、テスト内容に応じてDEBUGと使い分ける。

・開発および本番稼働時に使用するグローバルリソースの種別
- 種別は使用しない。

ファイルの保管場所


・読み込みおよび書き込みを行うファイルの保管場所
- /data/<コンポーネント名>下とする。
- 読み取り用は「input」、書き込み用は比較用データであれば「actual」、一時データであれば「tmp」下に配置する。期待する動作のデータは「expected」下。

命名規約


・全般
- シングルバイトのみ。日本語(ローマ字)は使用せず、英単語の組み合わせとする。
- 小文字のみとする。

・プロジェクト名
- 「<テストタスク名>_<コンポーネント名>」とする。

・環境変数名
- 「env_<機能名>」とする。
- 機能にない場合は一般的な用語(英単語)を使用する。

・スクリプト名
- 「<機能名>_<テスト観点名>」とする。

・スクリプト変数名
- 「scr_<機能名>」とする。

・コンポーネント名
- デフォルトとする。

・グローバルリソース名
- 「<テストタスク名>_<コンポーネント名>_<テスト観点名>」とする。

・サービス名
- スクリプト名と同一とする。ユーザ名は付与のまま。

・トリガー名
- 「<テストタスク名>_<トリガー名>_<テスト観点名>」とする。

スクリプトのデザイン


・グリッド
- 16*16グリッドとする。

・処理の流れ
- 左から右とする。
- コントロールコンポーネント(繰り返し処理やグループ処理など)は一段下げて配置する。
- コントロールコンポーネント内の処理は一段下げて配置する。

・アイコンの配置
- 配置メニューを使用し、均等に並べる

・例外監視の方法および例外処理時の動作
- 例外監視のメッセージは一律「期待する動作になりませんでした。」とする。

・アプリケーションログの出力メッセージ
- アプリケーションログ出力先設定は使用しない。

・コメントおよびメモの表記
- コメントおよびメモは表記しない。
- 必要な情報は別途テキストファイルに残す
(※) コメントの改修のためにスクリプトを修正する必要があるため、あえて別管理にしている




・スクリプト開発の経験が無い場合、開発前にガイドラインを確定するのが困難である。この場合、まずは簡単なガイドラインを策定した上で、一定の期間を設けて開発者同士で意見を交換しながら修正・追加しながら策定していくことが求められる。

 6 関連事項


・今後紹介する予定のすべてのパターンの前提となる

コメント

ログインしてコメントを残してください。

Powered by Zendesk