忍者ブログ
カレンダー
04 2024/05 06
S M T W T F S
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
プロフィール
HN:
[-_-;] (みかん)
性別:
男性
趣味:
プログラミング、XOPS
自己紹介:
中部地方在住です。
最新コメント
[11/30 NONAME]
[11/22 NONAME]
[09/24 NONAME]
[06/10 NONAME]
[01/29 NONAME]
XOPS関連サイト「みかん箱」の運営や、OpenXOPSの開発などを行う[-_-;](みかん)のブログ。近状報告や独り言などを書きます。
Prev Month12345678910111213141516171819202122232425262728293031Next Month
[PR]
×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

category :
PR
「XopsAddonCreator」の開発 -17
そろそろ夏休みですね。
学生として送れる夏休みも、残り少なくなってきましたのが寂しいです。

XopsAddonCreatorの件で、一部の方々にお願いするレビュー評価
(クローズアルファみたいなもの)を、早めることにしました。
当初の構想では、かなり一般公開できる状態の完成度にしてから
最終チェック的な位置付けでやっていただこうと考えていましたが、
開発途中で作りかけの試作品の試作品(プロトタイプ?)のレビュー
をお願いすることにします。
完成に近づける前に、開発の初期(厳密には中盤)に近い段階から
他の方々の意見を反映していった方が、結果的に良い物ができる
気がするからです。
最終チェックとしてお願いするのに比べ、作りかけの出来損ないを
お願いする形になることは、ご理解を願うしかありません。


今回は、非常にマニアックな回です。
当ブログのコメント欄にて、前から言っている「データ管理」について
ツッコミを頂いたので、自身で考えをまとめるためにも書いておこう
と思います。





ここで言う「データ」とは、システム内で扱われるブロックデータや
ポイントデータ、オプション設定値などです。
これらは、ユーザーがソフトウェア上でデータを編集するため、
値が常に書き換えられます。このデータの内部記憶や変更を
管理する概念を、自分は勝手に「データ管理」と呼んでいます。

例えば、ポイントデータの管理を考えてみます。
ポイントデータは、新規の何もない状態から、ポイントを新規に
作成し、編集し、削除し、データファイル(.pd1ファイル)から参照
・保存も行えます。コピー&ペーストもできるほか、テンプレート
機能、作成ウィザード機能もあります。
当たり前ですが、それぞれの処理は全てプログラムで記述され
定義されています。ある程度まとめて書くように気を付けては
いますが、1万行のソースコードに散りばめられているわけです。

ここで厄介なのが、データの編集を無効にできる「元に戻す」機能
と、(本家XOPSの仕様に由来する)最大数200個までという制限
です。
元に戻す機能を実装する方法にはいくつかありますが、一番
手っ取り早いのはデータの変更処理を実行する前に、丸々バック
アップを行うことです。
最大数の仕様制限は、主にデータが増える時に必要で、新規追加
やコピーの貼り付けなどの際に、事前に200個を超えないか
チェックする必要があります。

ポイントデータに(ポイントを)新規追加する処理は、
 ポイント数チェック ⇒ バックアップ ⇒ 新規追加
という処理になります。 同じくコピーの貼り付けも、
 ポイント数チェック ⇒ バックアップ ⇒ 貼り付け
となり、削除処理は、
 バックアップ ⇒ 削除
となります。 (削除はデータは増えないので上限チェックは不要)

このように、同じ「ポイント数チェック」や「バックアップ」を何度も
書いているわけです。
無論、ある程度関数(説明:略)にはまとめていますが、結局その
関数を呼び出す処理を何度も書いていることに変わりありません。
ここで、もし後で元に戻すためのバックアップ処理(の関数)を
書き忘れれば、『なぜか元に戻せない』というバグを生み、ポイント
数の上限チェックを忘れれば、ポイントが201個以上取り込め、
 表示などの他所で予期せぬ不具合が発生⇒エラーでソフトウェア
 が実行停止(死亡)⇒保存前にデータが吹っ飛んだ!
っとなったりします。

他にも、例えば「ファイルの読み込み処理でバグがあった」や「XOPS
ゲーム側で仕様変更があった」「やっぱXOPS2にも・・・」なので、
ポイントデータの形式が変わった場合、1万行のソースコード上から、
全てのポイントデータを取り扱っている部分を一行づつ探し出し、
修正しなければなりません。面倒ですし、またそこで間違える可能性
が出てきます。

感の良い人やオブジェクト指向(カプセル化)プログラミングをかじった
ことがある人なら気が付いたかもしれません。
多機能なポイントデータの取り扱いも、実は「追加」「編集」「削除」と
それらの「参照・読み出し」でしかありません。
「ポイント数チェック」「バックアップ」を含めたその4つの処理だけ書き、
ポイントデータの編集機能をそれら4つを組み合せて書けば良いのです。
例えば、ファイルを開く、コピーの貼り付け、テンプレート、ウィザード
の実行 の全てが、「(データの)追加」の処理を組み合せることで
実現できます。
こうすれば処理の書き忘れも起こりませんし、突然の仕様変更にも対応
できます。


現に、XopsAddonCreatorは元に戻す機能が怪しい気がします。
一度明らかにおかしい動作をしていたのですが、その際に見逃して
以降、その不具合に出会っていないのでわかりません。

処理を4つにまとめて組み合せるように書きなおせば、そんな不具合
は無くなるはずです。
どうしましょうかねぇ・・・。

最後に、長々と失礼しました。
category : ソフト・ツール開発 comment [1]
COMMENTS
【本文以外は任意項目です】
SUBJECT(タイトル)
NAME(お名前)
MAIL(メールアドレス)
HOME(サイトURL)
COMMENT(本文)
PASS(削除パスワード)
Secret?(管理者へのみ表示)

※スパム防止のため「Hello!」「website」「ブランド」「みかんの戦闘ブログ」
「http」などの一部キーワードを禁止しています。ご了承ください。

無題 2013.07.20 Sat 14:10 EDIT
記事ありがとうございます。

自分もこの問題にぶつかったことがあります。
バックアップを取ろうとすると、いろんな所で問題が起こりました。
結局、みかんさんと同じように、追加、編集、削除、呼び出しの4つを作り、ほぼそれだけを使って書きました。
書き直しに数日かかりましたが、バグはほとんど無くなりました。
時間をかけてでも書き直したほうがいいと思います。後々楽になりますし、コードの可読性も大幅に上がります。
ただ、多重バックアップに注意してください。
追加、編集、削除関数内にバックアップ関数を入れるため一度に複数のポイントを扱うと、バックアップが何回もされてしまいます。
from TK MAGURO
>書き直したほうがいいと思います。
一度諦めたのですが、考え直した末結局作り直しました。
完璧とは言えませんが、ある程度マシになった気がします。

TK MAGUROさんのご指摘通り、元に戻す機能のための
バックアップは実行タイミングがなかなか厄介です。
全体として単純作業のなかでも、その点は慎重に進めました。

アドバイスのほど、ありがとうございました。

<重複投稿されていたので一方を削除しました>
from MASTER 2013.07.24 Wed 00:43

※過去のブログ記事は 原則として編集・修正していません。
 各記事の内容は投稿時のものであり、現在では異なる場合があります。
 最新の情報は、関係する内容について書かれた 最新の記事をご覧ください。

TOP