「XopsAddonCreator」の開発 -17 | 2013.07.20 01:06 |
そろそろ夏休みですね。
学生として送れる夏休みも、残り少なくなってきましたのが寂しいです。
XopsAddonCreatorの件で、一部の方々にお願いするレビュー評価
(クローズアルファみたいなもの)を、早めることにしました。
当初の構想では、かなり一般公開できる状態の完成度にしてから
最終チェック的な位置付けでやっていただこうと考えていましたが、
開発途中で作りかけの試作品の試作品(プロトタイプ?)のレビュー
をお願いすることにします。
完成に近づける前に、開発の初期(厳密には中盤)に近い段階から
他の方々の意見を反映していった方が、結果的に良い物ができる
気がするからです。
最終チェックとしてお願いするのに比べ、作りかけの出来損ないを
お願いする形になることは、ご理解を願うしかありません。
今回は、非常にマニアックな回です。
当ブログのコメント欄にて、前から言っている「データ管理」について
ツッコミを頂いたので、自身で考えをまとめるためにも書いておこう
と思います。
学生として送れる夏休みも、残り少なくなってきましたのが寂しいです。
XopsAddonCreatorの件で、一部の方々にお願いするレビュー評価
(クローズアルファみたいなもの)を、早めることにしました。
当初の構想では、かなり一般公開できる状態の完成度にしてから
最終チェック的な位置付けでやっていただこうと考えていましたが、
開発途中で作りかけの試作品の試作品(プロトタイプ?)のレビュー
をお願いすることにします。
完成に近づける前に、開発の初期(厳密には中盤)に近い段階から
他の方々の意見を反映していった方が、結果的に良い物ができる
気がするからです。
最終チェックとしてお願いするのに比べ、作りかけの出来損ないを
お願いする形になることは、ご理解を願うしかありません。
今回は、非常にマニアックな回です。
当ブログのコメント欄にて、前から言っている「データ管理」について
ツッコミを頂いたので、自身で考えをまとめるためにも書いておこう
と思います。
ここで言う「データ」とは、システム内で扱われるブロックデータや
ポイントデータ、オプション設定値などです。
これらは、ユーザーがソフトウェア上でデータを編集するため、
値が常に書き換えられます。このデータの内部記憶や変更を
管理する概念を、自分は勝手に「データ管理」と呼んでいます。
例えば、ポイントデータの管理を考えてみます。
ポイントデータは、新規の何もない状態から、ポイントを新規に
作成し、編集し、削除し、データファイル(.pd1ファイル)から参照
・保存も行えます。コピー&ペーストもできるほか、テンプレート
機能、作成ウィザード機能もあります。
当たり前ですが、それぞれの処理は全てプログラムで記述され
定義されています。ある程度まとめて書くように気を付けては
いますが、1万行のソースコードに散りばめられているわけです。
ここで厄介なのが、データの編集を無効にできる「元に戻す」機能
と、(本家XOPSの仕様に由来する)最大数200個までという制限
です。
元に戻す機能を実装する方法にはいくつかありますが、一番
手っ取り早いのはデータの変更処理を実行する前に、丸々バック
アップを行うことです。
最大数の仕様制限は、主にデータが増える時に必要で、新規追加
やコピーの貼り付けなどの際に、事前に200個を超えないか
チェックする必要があります。
ポイントデータに(ポイントを)新規追加する処理は、
ポイント数チェック ⇒ バックアップ ⇒ 新規追加
という処理になります。 同じくコピーの貼り付けも、
ポイント数チェック ⇒ バックアップ ⇒ 貼り付け
となり、削除処理は、
バックアップ ⇒ 削除
となります。 (削除はデータは増えないので上限チェックは不要)
このように、同じ「ポイント数チェック」や「バックアップ」を何度も
書いているわけです。
無論、ある程度関数(説明:略)にはまとめていますが、結局その
関数を呼び出す処理を何度も書いていることに変わりありません。
ここで、もし後で元に戻すためのバックアップ処理(の関数)を
書き忘れれば、『なぜか元に戻せない』というバグを生み、ポイント
数の上限チェックを忘れれば、ポイントが201個以上取り込め、
表示などの他所で予期せぬ不具合が発生⇒エラーでソフトウェア
が実行停止(死亡)⇒保存前にデータが吹っ飛んだ!
っとなったりします。
他にも、例えば「ファイルの読み込み処理でバグがあった」や「XOPS
ゲーム側で仕様変更があった」「やっぱXOPS2にも・・・」なので、
ポイントデータの形式が変わった場合、1万行のソースコード上から、
全てのポイントデータを取り扱っている部分を一行づつ探し出し、
修正しなければなりません。面倒ですし、またそこで間違える可能性
が出てきます。
感の良い人やオブジェクト指向(カプセル化)プログラミングをかじった
ことがある人なら気が付いたかもしれません。
多機能なポイントデータの取り扱いも、実は「追加」「編集」「削除」と
それらの「参照・読み出し」でしかありません。
「ポイント数チェック」「バックアップ」を含めたその4つの処理だけ書き、
ポイントデータの編集機能をそれら4つを組み合せて書けば良いのです。
例えば、ファイルを開く、コピーの貼り付け、テンプレート、ウィザード
の実行 の全てが、「(データの)追加」の処理を組み合せることで
実現できます。
こうすれば処理の書き忘れも起こりませんし、突然の仕様変更にも対応
できます。
現に、XopsAddonCreatorは元に戻す機能が怪しい気がします。
一度明らかにおかしい動作をしていたのですが、その際に見逃して
以降、その不具合に出会っていないのでわかりません。
処理を4つにまとめて組み合せるように書きなおせば、そんな不具合
は無くなるはずです。
どうしましょうかねぇ・・・。
最後に、長々と失礼しました。
category : ソフト・ツール開発 | comment [1] |