Excelからプログラムを作る多言語対応オープンソース

元記事はこちら(まずコレを読んでください)

そして、黒歴史がまた作られる、と。

つーか、何を単純化したいのかさっぱり分からん。
この Excel に定義するような、簡単なレコード構造を Java で書くのって難しいかな？(もちろん反語ね)

詳細設計書に、フィールドの 1 つまで書かなければいけないような場合はいいのかもね。そんな設計書書いたらリファクタリングがまったくできなくなって話にならんけど。

一番の問題点は、フレームワークの宣伝ドキュメントばっかで、肝心の使い方がすげー分かりにくいことかな。

この手のツールの問題点はマーチン・ファウラーが既に指摘していて、(指摘してるのは、MDA に対してだけど、ソースコード自動生成ツール一般に対して当てはまる)

例えば、振る舞いのロジックを考えてみましょう。コーディングしてしまうより、シーケンス図やアクティビティ図を描くほうが生産的だなんて（ましてどちらかひとつを描くほうがさらに生産的だなんて）ことがあるでしょうか。コーディングがダイアグラムに比べて精密で膨大な量であったとしても、コーディングするほうがまだ生産性は高いと思います。コーディングすることで、実行したいときに実行でき、テストしたいと思ったときにテスト出来るわけですから。

とのこと。私もソースコードや、単体テストを書くほうが良いと思います。

あともう一つ。
モデルから自動生成される場合、結局モデルとソースが乖離してしまう、ということがあります。

ソースは自動生成された後、(必ず!)変更やリファクタリングが当然行われます。が、モデル側(すなわち自動生成の逆方向)に通知するメカニズムは通常持っていません。ソースが変更されてから、設計(モデル)が変更されるような場合、この状態で自動生成を行ってしまうと、ソースの変更が消えてしまうのです。 (自分の見てきたものでは 4GL のツールがそうだったし、SODEC で見た比較的最近のツールでもそうだった)

まあこの問題はツールが進歩すればうまく対応できるだろうし、このフレームワークはもしかしたら対応してるのかもしれない。(もし対応できているのなら、それは素晴らしいセールスポイントだと思う)

でも、私としては、おとなしくソースをきっちり書くのが一番大切だと思うけどなぁ。