アカウント名:
パスワード:
こういったフレームワークって, 大前提として前工程のシステム設計を, オブジェクト指向なりなんなりの比較的現代的な手法で行わないと効果半減なんですよね. 一方, 銀行業務システムを設計する人って, 多くが20年前の第二次オンラインの時のシステムに縛られているんで, 20年前の設計手法(フローチャートとレコード定義のレベル)に留まっている人が多いってのも事実で.
ですから, この場合
のどちらかってことになると思います. 前者は, まあ言ってみれば設計のやりなおしですから, 出来れば理想的なんですが, 現実には難しいです. ということで, 普通は後者のパターンに行っちゃうことが多いです.
で, 最終的に出てきたコードを見ると, 使用言語にかかわらず, 20年前のCOBOLと同一パターンで
なんて具合になっています. もうこうなると言語仕様がどうこうなんてレベルじゃないですね. Prologぐらい根本的な思想の違いがなければ, 100年ぐらい変わらないんじゃないですかね.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
過信だったら大変 (スコア:2, 興味深い)
と思ってるだけで実はかなりいい加減なことをやらかしてたら・・・とか思うと怖いですね。
Javaが初めてだろうと、別言語での経験があれば、言語間の差なんて誤差レベルだと思うのは#982975 [srad.jp]のコメントの通りなのですが。
木に竹を継いでも (スコア:3, 興味深い)
こういったフレームワークって, 大前提として前工程のシステム設計を, オブジェクト指向なりなんなりの比較的現代的な手法で行わないと効果半減なんですよね. 一方, 銀行業務システムを設計する人って, 多くが20年前の第二次オンラインの時のシステムに縛られているんで, 20年前の設計手法(フローチャートとレコード定義のレベル)に留まっている人が多いってのも事実で.
ですから, この場合
のどちらかってことになると思います. 前者は, まあ言ってみれば設計のやりなおしですから, 出来れば理想的なんですが, 現実には難しいです. ということで, 普通は後者のパターンに行っちゃうことが多いです.
で, 最終的に出てきたコードを見ると, 使用言語にかかわらず, 20年前のCOBOLと同一パターンで
なんて具合になっています. もうこうなると言語仕様がどうこうなんてレベルじゃないですね. Prologぐらい根本的な思想の違いがなければ, 100年ぐらい変わらないんじゃないですかね.
Re:木に竹を継いでも (スコア:2, 興味深い)
Javaでこれやっちゃうとぬるぽと配列の境界値制限超えでプログラムから例外が数多く出ることになります。
1000行のうちの最初の100行がnullと空文字列チェックのif文とログ出力のコピペが延々と続くのをよく見ます。
引数がクラスであればメンバがほぼ全てString、クラスでなければほぼStringなわけです。
いいかげんになんでもIDにしてしまう設計を見直さないと生産性向上とか品質向上ができないと思うのですが、皆様の開発現場ではどうでしょうか？
ログ出力ならともかくソースコード上で延々とIDを見せられるとデバッグに余計な集中力がいってたまりません。
Re:木に竹を継いでも (スコア:1)
それがさー、
微、妙～にコピペじゃなかったりするんですよー。
（以下５万行の愚痴削除）
Re:木に竹を継いでも (スコア:0)
＞できないと思うのですが、皆様の開発現場ではどうでしょうか？
思い切って変数名からメソッド名からクラス名まで
全部日本語採用、名前そのままで扱います。
Netbeans周りだけは日本語クラス名だとうまく動かない
ところがあるので残念ながら英語やIDです。
Re:木に竹を継いでも (スコア:1)
あと、設計もSeasarプロジェクトからだしてるgoyaという手法を使えば大丈夫・・・なハズなんですよ。なんですけど多分そんなわけないですよね。おっしゃりたいことはよくわかります。
＃いまやってるシステムがちょうどそういう感じのソースコードなので恨みを込めてID
Re:過信だったら大変 (スコア:1)
こういう明らかなインチキに対して、この技術基盤を選択した人がどういう態度を取るべきか。私は、そういう誤解をといていって、その上で、そのフレームワークを使うことの具体的な効能を説明できるようにしておくことが必要だと思いますよ。
オープンソースの味方になってくれそうな人だったり記者だったりしたとしても、間違いは細かく言って、それでも間違いを続ける人だったらオープンソースコミュニティの支持者であったとしても「迷惑だからあんまりあれこれ言わないでください」とお願いするしかないでしょう。
Re:過信だったら大変 (スコア:0)
別言語のスキルさえあればなんとでもなるさ。
Re:過信だったら大変 (スコア:0)
>誤差レベルだと思うのは#982975のコメントの通りなのですが。
そう主張する人は多いけど、大抵は自分の無知を知らない
だけだと思う。一度も使いこなしたことがないから、自分が使い
こなせていないことにも気付かない。「無知の知」は現代のITでも
重要です。
実際には言語間の差よりも、設計思想や世代間の差の方が
大きいけどね。いずれにせよ、それこそGoFもEffectiveJavaも
知らないような旧世代の人にJavaが満足に使えるとは思えない。