アカウント名:
パスワード:
こういったフレームワークって, 大前提として前工程のシステム設計を, オブジェクト指向なりなんなりの比較的現代的な手法で行わないと効果半減なんですよね. 一方, 銀行業務システムを設計する人って, 多くが20年前の第二次オンラインの時のシステムに縛られているんで, 20年前の設計手法(フローチャートとレコード定義のレベル)に留まっている人が多いってのも事実で.
ですから, この場合
のどちらかってことになると思います. 前者は, まあ言ってみ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
過信だったら大変 (スコア:2, 興味深い)
と思ってるだけで実はかなりいい加減なことをやらかしてたら・・・とか思うと怖いですね。
Javaが初めてだろうと、別言語での経験があれば、言語間の差なんて誤差レベルだと思うのは#982975 [srad.jp]のコメントの通りなのですが。
木に竹を継いでも (スコア:3, 興味深い)
こういったフレームワークって, 大前提として前工程のシステム設計を, オブジェクト指向なりなんなりの比較的現代的な手法で行わないと効果半減なんですよね. 一方, 銀行業務システムを設計する人って, 多くが20年前の第二次オンラインの時のシステムに縛られているんで, 20年前の設計手法(フローチャートとレコード定義のレベル)に留まっている人が多いってのも事実で.
ですから, この場合
のどちらかってことになると思います. 前者は, まあ言ってみ
Re:木に竹を継いでも (スコア:2, 興味深い)
Javaでこれやっちゃうとぬるぽと配列の境界値制限超えでプログラムから例外が数多く出ることになります。
1000行のうちの最初の100行がnullと空文字列チェックのif文とログ出力のコピペが延々と続くのをよく見ます。
引数がクラスであればメンバがほぼ全てString、クラスでなければほぼStringなわけです。
いいかげんになんでもIDにしてしまう設計を見直さないと生産性向上とか品質向上ができないと思うのですが、皆様の開発現場ではどうでしょうか?
ログ出力ならともかくソースコード上で延々とIDを見せられるとデバッグに余計な集中力がいってたまりません。
Re:木に竹を継いでも (スコア:1)
それがさー、
微、妙~にコピペじゃなかったりするんですよー。
(以下5万行の愚痴削除)