Javaでのシステム開発は手の施しようが無い。
そう思うようになった。
詳しくは書かないけど、
今回も

完成品しか眼中にないシロモノだった。

思うに『物造り日本』が前世期の歴史になってしまい

完璧なものが出来ているなら単体のテストはサラっと動くハズ。

そこで手間取ると云うことは、製造（色々なファイル）段階の品質が悪い。

と思う

消費者指向のシステムエンジニア

が数多くいるのだろう。
少し違うかもしれないけど

コアゲーマーなシステムエンジニア

と云った方が意味が通じるかもしれない。
※プレイするけど製品は作らないという意味。
※ボクはライト系ゲーマーです。
※そう云う背景もあってゲーム開発には今も一切係わっていません。
こうなってくると、

今はソースを書いたら負けです！

としか言いようが無い。
ソフトウェア開発で「同じ内容の仕様書」を見て「考えながら同じソースを書く」ことはまず起きません。
なぜなら、同じものならファイルをコピーするだけでいくらでも量産できるからです。
ですから、ソフトウェア開発は試作品を作るのと同じです。
試作品ですから、その設計書を読み、パーツを作り、組み立て、塗装してみたら

クズだった！

となることがあっても当然です。
※普通、考えた時はイケルと思ったけどなぁ～な結果を量産品で出さないための試作品ですからね。
そして、特注品な訳ですから、その経験が生きるのはクズのリテイクを泣きながらやっている時だけです。他に応用が効く訳もありません。ただ用心深くなり人を見れば疑い出すだけです。
生産性を高めると云われているワークフレ－ムも判りやすく且つ品の良い言葉を選べば、
優秀な自己流プログラミングは他人に読める訳がない法則（※特にJavaScript）
に従っていて大抵はクズなのです。
すれっからしのStrutsの良さは、注意書きのストックがいっぱいあるということであり、扱いやすい訳ではありません。
※それでも新しい（怪しい）ワークフレームよりはマシかもしれません。
その最左翼と云える『jQueryの人気に便乗して開発中のNode.js』は今どうでしょうか？
いつになってもＶｅｒ．１.0が出ることがないような気もします。
なんとなく懐かしいザナドゥ・プロジェクトなんかも思い出しちゃいますね。※結局、自然消滅。
閑話休題。
で、その仕様書なりフレームワークなりの意味するところを一番理解した時がやってくるのはシステム開発終了。つまり最後まで試行錯誤が続くわけですね。
まとめると

システム開発

のはずが

• システムを構成するワークフレーム

 

• 開発手法

 

• 開発ツール

 

• 品質管理

 

等などの

 

『実証実験』

に成り下がってしまうのです。

• サーバーの余力があれば云いたい放題！

 

• サーバーの余力が無くなれば禁則事項の乱発！

 
という話はどこでも聞く話です。

貧層なホストを

 

なんとか使っていたＣＯＢＯＬ時代より

 

寒い時代になったものだ

 
 
と云ってよろしいのではないでしょうか。（濠泣
 
それらの顛末から得た教訓は、
Ａ　と　Ｂ　を組み合わせると、必ず両方の悪い点が露呈する。
例えば、すれっからしのStrutsは、XMLをジョブ制御に見立てて色々なリソースを実行する仕組みですが、デバッグは実機でよろしく！となっています。勿論Eclipseでデバッグできるような仕組みがある場合もありますが、無い時もあります。
では、実機が存在しないのにどうテストするの？と云えば、

完璧ならちょっとテストすればOKだよね？

の方針はここでも生きています。
それでもJavaのシステム開発に手を出す理由と云えば・・・
マシなところをまだ知らないだけでは？と思っているからです。
今のところ、ハズレだけですけどね。
いつかは・・・と思いたいですね。
ボクなりの解釈では、JavaScriptにJavaコンパイラを載せれば全て解決できると思っています。
そう、なんでもJavaで書けばいいのです。
ではEclipseは最高？と云えば、そうではありませんね。
無理やり作り上げてる感じでいっぱいです。
ワークスペースはよく壊れますし、最悪の場合は起動すらしないバージョンもあります。
なぜ、そうなってしまったのかは、沢山の人の手で努力と汗で作られたので、思い違いな箇所がやっぱりあるのでしょう。
Javaだけでもそんな感じですから、単純にJavaと何かを組み合わせると、もう途端にダメになります。
Javaソースだけで出来ていればEclipseがあればNot Found Classなどと指摘され実際に動かす前にソースが足りない事も事前に察知できますよね。
誰かがXMLやプロパティファイルからJavaコードをマッピングするアイデアをここに差し込むと、このアイデアが重大な欠陥を呼び起こします。
EclipseがXMLやプロパティファイルに書いた参照クラスが実在しなくてもNot Found Classと指摘してくれないのです。
たったそれだけのことですが、動かしてみないと判らないシロモノに劣化してしまうのです。
そして大抵は動かなくなった場所でプログラムが異常終了。その先どうなるのかは想像するしかありません。オマケに止まった場所から再開できることはまずありません（継続できそうもないので停止したんですから）ので、この先のバグは？１個？１００００個？そんなの判る訳が無いので、見通しなんてただの思い付き、ソコが非常に困ります。
EclipseにはJavaソースのimportsとClassPathを頼りに探索するプラグインが入っており、これが【問題】ビューに色々と悩みを書き込んでくれるのですが、そこにXMLやプロパティファイルで疑似的なクラスパスを実装しても探索不能になるのも当然です。
それでも、独自仕様のXMLに参照クラスを書いても、これを手がかりに探索するプラグインを作り同じ様にNot Found Classと【問題】ビューに書き込めば良いのですが、当然ながら何種類もの設定方法があったりすると、正しいのか間違っているのかTRUE/FALSEで判断するのも難しくその判断のため、独自の設定が別途に必要になったり、その設定ミスが原因でNot Found Classが出ない可能性もあり得ます。
消費者指向のシステムエンジニアは、

完璧なものが出来ているなら単体のテストはサラっと動くハズ。

そこで手間取ると云うことは、製造（色々なファイル）段階の品質が悪い。

どうやっても最後にはここにたどり着いてしまいます。
なぜなら、消費者指向エンジニアですから『無謀な納期、気まぐれな仕様の変更や追加、つまりサプライズハプニングが大好きで、その経過を見学することに生きがいヤリガイを感じているようです。』ですから、プラグイン開発にも『後出し』することになります。
そんな状況でも『どんな無理な要求にも対応し素晴らしいプラグイン』を作りあげたとしも、末端のプログラマーにリリースされるまでの長い期間の間は『いつも機能不全なプラグイン』でしかないのです。
そして、ついに

予算と時間をかけてプラグインを作る

と誰かが一大決心をした場合にはもっと状況が悪化します。
予算と時間をかければリリースは大幅に遅れるのも当然ですよね？
※試作品ですから
もしかすると開発終了後にリリースされるかもしれませんね？
と云う訳で、どんな些細なものでも、

いつも機能不全なプラグイン

しか手に入らない体制であり、
ひたすらソースを目視し直観に頼るしか手が無いのです。
よくよく考えると、

最初から打つ手がないんだね。

Eclipse？
あんなの飾りですよ！
偉い人には判らないのですよ！
でもEclipseが無かったら？
もっと酷いことになることは間違いありません！
JavaDocのバルーン・ヘルプも無く、XMLを何かに読み込ませたり、Javaソースをコンパイルするまで単純な文法エラーすら気が付かないでしょうからね。
そうそう最近は３Dプリンタがありますよね。
どうせ試作品同然のシステム開発なら、仕様書を読み込んでとりあえず３Dプリンタみたいにソースをでっちあげるツールはできないのでしょうか？
実際そういうのもあるのですが、大枠のプロジェクトや大まかなクラスを決め打ちで出すものやBeanに特化したものなど色々です。しかしいずれも、やはり作れない部分があります。残りの部分（多いか少ないかは色々）は、ツールの都合に合わせて、Javaコードや設定ファイルをあちこち張り合わることになります。どう云う訳か色々なツールを組み合わせて一式でっちあげるという流れになることがありません。
そうなると、結局、ツールに合わせて、色々試行錯誤し、考えたりする手間が増えるだけなんです。
なぜそうなってしまうのか？無能なのでしょうか？
ボクは、仕事が無くなるのが嫌なので、ちゃんとしたツールは「使わない」「作らない」「売らない」の3原則を掲げて厳守しているのだろうと思っています。（大笑