それもそろそろ終わりなのか、最近は風が秋の風っぽくなってまいりました。
今月1か月は仕事がすこぶる大変でこんな仕事もう辞めてやるー!状態でしたがそれでも大分消化できたので落ち着いてきています。
作るにあたって設計をするのはもちろんのことなのですが、こうも時間がないと細かいところの作りは荒くなってしまいます。
いろいろ好き勝手にやらせた結果、似たような処理があちこちにあるのが心苦しいですが時間があれば直したい。
ただ一番破綻してはいけない部分だけは守り抜いたのでおかしなバグはそうそう起きないことを願いたい。
そんなわけで今日の日記のお題は「止まらないアプリを作るには」と「許される破綻と許されない破綻」です。
止まるアプリはどういうところで止まるかというと大抵はNullReferenceとIndexOutOfRangeです。
特に多いのは配列外。
アプリ内で発生するとハングアップ当然の状態になります。
配列をさわるときは要注意。入口には必ず有効チェックを入れなきゃやってられません。
int get( int index ){
if( index = m_array.Length ) return 0;
return m_array[index];
}
void set( int index , int value ){
if( index = m_array.Length ) return;
m_array[index] = value;
}
許さないデータなら弾くという作りにすれば配列外例外の発生率はググンとさがります。
そしてNull例外
Null例外を防ぐ方法は多々あり、何もしないNullオブジェクトを作って初期値にそのオブジェクトを入れておくとかです。
なんらかしらの場所にアクセスしていれば例外は発生せずにアプリが進行するという方法です。
もしくは「そもそもインスタンスを簡単に渡すな」という考えのもと、インスタンスのデータだけを見る窓口を作るという方法もあります。
public static int getEnemyPosX( int enemyid ){
Enemy e = ObjectManager.Find( enemyid );
if( e != null ){
return e.pos.x;
}
return 0;
}
public static int getEnemyPosY( int enemyid ){
Enemy e = ObjectManager.Find( enemyid );
if( e != null ){
return e.pos.y;
}
return 0;
}
利用者は各パラメータを安全なデータで手に入れることができます。
インスタンスを利用する場所と配列を利用する全ての場所に上記のような窓口を用意するだけで
大抵の例外は発生しなくなる。
へんな番号を返して期待しないIDが返ってきておかしな画像を表示したり動作を起こすこともあるが、
局所的に発生するためバグは追い易いと言えます。
そして次に「許される破綻と許されない破綻」
実はプログラムには不細工に書いても「まぁそこだったら別にいいよ」ってなる場所と「そこは適当に書くんじゃねぇカス」って場所があります。
絶対適当に書いてはいけないのはデータ周り全般、そしてアプリの下回り設計・マネージャー層です。
ある程度泥臭くても、不細工でも許されるのはロジック部分です。
パズルゲームの連鎖判定とかシューティングの弾幕の移動計算とか、
細かい演出など計算処理がメインの場所などはある程度力技でもどうにかなる。
むしろゲームに関していえば仕様が度々変わるので時間をかけてカッコいい計算処理を書くよりは
とりあえず動いているように見えるものを作ったほうが後で苦労したのに全部切り捨てて一から~ってなったときにモチベーションが下がりません。
ゲームというのはあたかも複雑で高度な計算で動いてるように見せかけて凄い誤魔化しまくってるものが多いのです。
その誤魔化しが許されるのはやっぱり下の作りがあるからだと思います。
この「下の作り」と「上の作り」がごっちゃになったプログラムは一番ヤバイです。
面倒な処理の中に面倒な処理がまざれば相乗効果で悪くなります。
同じベクトル持ったバグは無敵です。
というようなことが書きたかったので書きます。
逆に言えばデータの有効チェックをするのに特別な技能は必要なくて、これは新人でもアルバイトでもプログラム初心者でもできることだし
少なくともバグるなら自分が書いたところだけバグるように作ろう、と思えばバグの発生個所も局所的なものになるので
プログラミングというのは高度な数学知識とかアルゴリズムの理解度ではなく、
人として当たり前のことができていればそれだけでいいんじゃないかと感じたりもします、今日この頃
ではでは