作ったモノへの評価の難しさ 反省編

　前回からずいぶん間が空いてしまいましたが、反省をしてみたいと思います。とりあえずダメだった（ダメになってしまった）部分を列挙。

・構想があったものの、その構想を絞って限定的なものにしてしまった。
・内部仕様を作ってる途中で（何度も）変更した。
・GUI部分とソフトのコア部分を切り分けずに作ってしまった。
・System.Windows.Formの理解が浅かった。

　さて、一つ一つ見ていきます。まず一つ目。構想があったというのは、アニメを作りやすい環境を作るということです。絞って限定的なものにしたというのは機能を妥協して自分がプログラムしやすいものに変更した点に問題がありました。
この場合は自分のスキル不足が関係していて、理解できる範囲で作ろうとした事に原因があります。しかし理解せずにプログラムを組むことは不可能であって、それを補うためのブラックボックス的なライブラリがあったとしても、ブラックボックス部分を知らないとどちらにしろ満足に扱えず、バグを生んでしまうという危険があります。
　二つ目。これはメモリ（バッファ）への一時格納と、独自ファイル拡張子での保存を考えてたら、理解できる範囲でアレコレやってたら、それ以外の機能の内部仕様を弄くることになりました。このせいで実装したかった機能が詰めなかったという結果になりました。メモリ圧迫を無視した場合、何百メガのメモリを食う結果を見てしまい、焦って実装したのが悪かったのかもしれません。
　三つ目。GUI部分はあくまで処理（イベント）を起こさせるだけのものなので、GUIに依存させないためにプログラムのコアを分けて作るべきでしたが、問題なくスラスラ書けてしまったために後でGUIの変更をしたくてもできなくなってしまいました。まったくもって間抜けでした。
　四つ目。三つ目に関係しますが、Formの挙動を理解していなかったのが今回最も反省するべき点です。今回DIBを使って前後のレイヤーと下絵を表示しているのですが、これが遅くて遅くて…。メモリ圧迫を無視して作るならDirectXを使うことを考えていたのですが、どうにも面倒で仕方なかったのでかなりやっつけで半透過表示を実装したのが逆にパフォーマンスの低下を促してしまったのかもしれません。

今回まともにFormを使ったプログラミングだったのですが、使っていくうちにボロボロになってしまいました。一応例外落ちやバグは出ないつくりにはなってると思いますが、確証は取れないのが痛いところです。Fixしようとしても一から作り直したほうが早いという結論があります。
とりあえず作ってる最中は夢に見るまで悩むことが多いので、これがなくなればもうちょっと楽にプログラミングできるのではないか？と思います。

＃夢にまでプログラミングする事が出てくるのは寝てるのに休んでる気がしない…