ここ最近はもっぱらVB6に戻っている。
画面を好き放題制御できるの楽しい( ´∀`)w
ブラウザとは違うな〜とおもいつつも不便な点がないでもない。


.Netで作り上げたDBアクセスクラスの速攻作成のための道具がつかえない。
Javaで作り上げた同様のクラス構成がとれない。
PHPですら用意してたのに今それができない。
ってことはあれだ。
1テーブル追加したときにSQL文かいて構成作るために必要な時間は必然としてかかるってことだ。
上記3つなら1ケタ分単位でつくれるのに、今約1時間。


それはそれとして。
かつての自分が組み上げてたのがVBの今のソース。
言語特性を利用して作ってたのが.NetとJava
それに追随したのがPHP
あれね。
頭の中にあった開発更新メンテナンスしやすいDB構成、クラス構成は変わらないね。
言語にあわせたソース記述するさいに、できること出来ないこと、
面倒くさくなること、楽になることは
それぞれぜーーーんぜん違うのでその差分調整に四苦八苦している今に気が付いた。


これが何を意味するか。
『構成として取るべき形に変わりは無い』
ただ言語や開発環境の特性により、開発のしやすさ、保守のしやすさは
大いに変わるので、その辺を考慮したソースの形式は影響を受ける。


.Netのregion使えばソースを折りたためるから、1機能を作成するのに、
メソッドが増えても機能のまとめができれいれば、行数が増えてもさして気にならない。
各種ファイルもツリー構造で管理できるから、構成さえしっかりしていればさして気にもならない。
JavaでもEclipseの最近のだと似たよなことができる。
しかして、Script系のだとそんなもんはもちろんないから、1ファイルあたりの行数が増えることは
それそのまま理解されにくいことに繋がる。
VBに至ってはエディタの都合上ファイル数が増えると、ファイルが探しにくくなるので
できる限りファイル数を抑えようとするココロが働く。


取るべき構成が同じでありながら、それぞれはそれぞれの形式をとるようになっていくのだ。
JavaでReflectionを使い開発の効率化を図り、
.Netに生かそうと思ってみれば、構成上よりシンプルになれるDelegateがあった。
PHPでも同じの作ってみようとしてみたら、連装配列のもつ記述の楽さ加減にココロ奪われそうになった。


処理上必要なややこしいところをできるだけ隠す。
ややこしいところをできるだけ少人数相手にしか公開しないような仕組み作りを心がける。
ソース開発に携わるメンバー全員がReflectionだのDelegateの実装方式を知らなきゃいけないような
構成は必ず致命的な不具合を呼ぶ。
コア以外のソース構築はできる限り勘違いのしようも無いような形式で記述できるほうがのぞましい。
リストの設定だけで画面ができるとか。


ってなことを。
やってきたおいらが。
今あえてVB6でやるかやるまいかの岐路にいてる。
構築の美しさを求めれば再構築になる。
再構築してもその構築結果と道中の開発過程のツールを今後使うのかといわれたら悩ましい。