なんでJavaのプログラムでCOBOLチックなコードが出来上がっちゃうのか？を考えてみた - おろかな日々（情報元のブックマーク数）
どきっ・・・GoogleAppEngineでCOBOLみたいなコードを書いちゃったよ・・・俺。。。
日本SI業界においてネットや書籍で多くの人から評価されないJavaコードの大半は、この試験の問題が象徴しているような低品質のものが多いということがやはり事実ではないでしょうか？
なんでJavaのプログラムでCOBOLチックなコードが出来上がっちゃうのか？を考えてみた - おろかな日々
エンタープライズの場合は、COBOLのコンバートやリホストとかで、既存を動かすことが第一優先だしね。。。しょうがないといえばしょうがない。
特にEDPの分野では「事務の効率化」が仕事としてプログラムを作る動機であって、当時必要十分だったCOBOLを使ったシステムを当時既に作ってしまっていたという事情もあり、技術に対して保守的だっていう背景があるので、ゲーム業界の人よりも深刻だ。そして、ここで生じたミスマッチというのが、Webの日記やtwitterなんかで指摘される。クラスがクラスになってないとか、継承がないとか、ヘンな命名規約があるとか。それがもし新規で作られたシステムの新規でつくられたプログラムなのだとしたら、きっと技術者のスキルに問題があるのだろう。その場合はそれを問題にするべきだ。
なんでJavaのプログラムでCOBOLチックなコードが出来上がっちゃうのか？を考えてみた - おろかな日々
ポリシーとして、必要最低限以外変えないという形で、リプレースしちゃうと、そうなりますよね。
昔からあるシステムは大昔にCOBOLで書かれる事を前提に分析・設計しているわけです。で、さあこれをシステム更改しましょう！となったとき、その理由は「事務のプロセスを見直して会社組織全体の効率を改善しよう！」*2なんていうものではなく「今使っている大型汎用機、ハードウェア保守期限切れだからシステム更改しないとだめだってさ。」、あるいは「大型汎用機の維持コスト高いから、小型のPCサーバにダウンサイジングしましょう！」だったんです、大抵の場合。後者の２つの理由の時、設計を見直す理由はない。むしろ、プログラムなんかは変えずにそのまま移行できれば最高だ。でもここで、「Webシステムとして再構築しましょう。」になってしまった。理由はいくつか考えられる。
- JCLやハードウェア依存の部分があったりしてPCサーバに移すにしろどうせCOBOLをそのままは移行できない。
- 必要な部分だけ改修をかけたいけど、年々減っているCOBOL技術者の調達が難しい。
- Java技術者のほうがCOBOL技術者よりは調達が容易。
- ベンダーがCOBOL to Javaの移行ツールを提供している。機械的変換ができれば楽（コスト削減）
- 中国への発注で人件費削減。要求は「このCOBOLと同じプログラムをJavaで作って！」これなら発注は簡単。
- Javaの方が生産性が高い(但し、COBOLの移行に使う前提で成り立つかは激しく微妙ｗ)
こんなところか。あと、仕様・設計レベルの見直しがやりたくても出来ない理由というのもいくつか考えられる。
なんでJavaのプログラムでCOBOLチックなコードが出来上がっちゃうのか？を考えてみた - おろかな日々
- 現場の利用者（事務処理をしているオペレータ）の要求は「今のやり方を変えないでくれ」。
- そもそも、設計書・仕様書がない。→今のプログラムの通りにするしかない。
- 設計のやり直しをするにも、要求分析からやり直すにしろ、金がかかる。
- やんなきゃいけない理由（保守期限切れ、コスト削減）からして、そんなにお金をかける理由は無い。
