南極の図書館

ペンギンが寝ていた…。

元コボラーとして一言言っておこう>COBOLこそスピード経営に必要

COBOLこそスピード経営に必要(キリッ)
誕生50周年、社会を支え続けるCOBOL - COBOLこそスピード経営に必要:ITpro


あのジャパネットたかたさんの言うことなので、確かにそういう面もあるんだろうけど。
私がシステム作った時は大変だったよ。
やっぱり業務システムはオブジェクトで考えた方がいい。

とりあえず記事に突っ込み

>COBOLを使い続けます。他の言語にする必要は全く感じていません。理由は二つあります。一つは高い生産性です。私の経験では、ビジネスロジックの部分をVBで書き換えた場合、開発期間はCOBOLの1.5倍程度に伸びます。

比較対象のVBを深く知らないから何とも言えませんが、ビジネスロジックVBと比較することが間違い。


>ただオープン化に伴って、4GL(第4世代言語)で記述していた画面は、すべてC#で書き換えました。4GLの生産性は高いものの、オープン環境では動かなかったのが原因です。

重要です。


>データベースアクセスも、データベースソフトを変更したため、ストアドプロシージャを呼び出すように変更しています。

重要です。。。
ここまで読んで感じるのは、画面がC#でDBは何か分からないけど「変更した」と言うくらいなので最近のものだろうし、勝因はソレではないのか??


>最新のCOBOL規格では、他の開発言語で作ったアプリケーションから呼び出せるようになっていますから、部品化や標準化を進められるでしょう。

なぜそこまでしてCOBOLなのだろう?


COBOLがいい理由

考えてみると、昔からバリバリやってきた人には「動的なひな形(自動生成)」が出来るコードは「ありえない」かもしれない。
Java(のフレームワーク)も「設定ファイル書いたら動くとか、そんなのプログラムじゃねえ!」と思うかもしれないし、まぁ気持ちはわかる。


何をしても、最終的に「うまくいっている」ならそれでいいんだよね。
「保守が容易」で「みんなが読める」なら確かに一部をCOBOLで作るのも、悪くないのかもしれない。
記事を読むと、ロジック>>>>画面=DBみたいな意識で作ってるようにも受け取れるし、重要な部分はCOBOLで!と思ってるならそれでもいい。
私は、画面>>>>>>DB=ロジックと思ってるから「画面がC#なら、まぁ楽に作れるかもね」というのが素朴な感想なんだけど。

私の経験から

一番記憶に残ってるのは、過去私がやったCOBOL開発で「似たような業務」を実装するときは「元のソースをコピペして、違う部分だけ変える」という原始的な手法だったから、クラスが無いのが恨めしかった。
ここもはRoRのDRYという意識ももちろんあるけど、そこまで突き詰めないとしても、クラス作って継承したら終わりでしょう、と思ってしまう。


当時は「業務分析」から行ったけど、COBOLで組むと分かってる時点で「開発へのフィードバック」を意識して分析することはあまりなかった。
UMLでいうクラス図から作るようなプロジェクトでは分析はホントに神経を使うのだが、そのときは単純に「漏れなく被りなく」それだけだった。MECEさえ守ればいいだろうと。実際その後は力作業だった。コピペの嵐。


テストも大変だった。
継承ならば「コピペミス」なんて無いのになぁ、と実感したし、xUnitのようなプラグインがないのも辛かった。
(私が知らないだけで、立派な単体テストツールはあるかもしれません。)


それらも含めて、一番つらかったのはやっぱりUIと帳票。
画面遷移にしろ、最終アウトプット(大体は帳票)にしろ、どうもしっくりこないんだよね。
顧客との折衝で「画面に入りきらないので」なんて、今思えば良く言ったし、良く受け入れられたと思う。(実際無理だったから仕方ないのだが)


なんて、懐かしんだりして。
当時の経験は、Javaを書くときも、Rubyを書くときも、かなり役に立ってます。
COBOL以外をやらない人間はどうかと思うけど、知識の一つとして持っておく分には良いと思う。