COBOLコードの近代化はどのように進めるべきか 165
ストーリー by morihide
2000億行って多いの？ 意外に少ないの？ 部門より
2000億行って多いの？ 意外に少ないの？ 部門より
Open Tech Pressに「2000億行もの負の遺産――COBOLコードの近代化はどのように進めるべきか」という記事が掲載されています。コボラー人口の減少に伴い保守が難しくなっているCOBOLアプリケーションをどうやって引退させるか、という記事です。要約すると、COBOLアプリケーションにも“グローバル変数やGOTOステートメントが無秩序に使われている”ダメダメなものから保守のことまで配慮して作られているものまであり、またアプリケーションごとに重要性も異なるので、既存のアプリケーションポートフォリオの状況をしっかりと把握し、個々のアプリケーションごとにどのような方法で近代化するか（あるいはしないか）をプランニングすることが重要である、とのことです。
「終わってるITスキルトップ10」で堂々の第一位を獲得したCOBOLですが、皆さんの職場ではCOBOLアプリケーションの(近代化|延命)計画をどうしてますか？
Java屋なんですが・・・ (スコア:5, 興味深い)
以前聞いたことがあるのは、
・コボラーには２種類いた。「設計・実装バリバリ」と「言われたコードしかかけない」。
・前者はコボルが時代遅れになっても、別環境･別言語でやっていけた。
・後者はまさしく「負の遺産」。後者が(無理に)やった設計･実装も負の遺産
だとか。
自分自身のコードを見てて、後で再度見て理解できるものもあれば、目を覆いたくなるようなものもあります。後者の人が書いて、かつそれがメインストリームから外れたコボルだったとき・・・捨てるしかないんじゃないかな？「下手なリフォームは、新築より金がかかる。」
自分も前者になれるように、日々精進です。
-- gonta --
"May Macintosh be with you"
Re:Java屋なんですが・・・ (スコア:5, おもしろおかしい)
ソレ系業界の人間じゃないので，ふと興味を持ちました．COBOLプログラマを「コボラー」と呼ぶのであれば，Javaプログラマを「ジャバー」とか，Cプログラマを「シャー」とか呼ぶんでしょうか？
Re:Java屋なんですが・・・ (スコア:5, おもしろおかしい)
この際、NetHack的な方向に改名を進め、COBOL屋さんをコボルト、Javaの人をジャバウォック、Cプログラマはシーサーペントと呼ぼう。
当然、Python はジャイアントパイソンです。
Re:Java屋なんですが・・・ (スコア:1)
Re:Java屋なんですが・・・ (スコア:3, すばらしい洞察)
ごく限られた本当に凄い人も、大部分のそうじゃない人も、箸にも棒にも引っかからない
ダメな人も清濁併せ呑んでこそのマス言語、大衆言語であり、昔はそれがCOBOLだったし、
今ならJavaになるんですかね？
そういう言語があるおかげで、一部の貴族言語が「美しい設計」だの「〇〇使ってる技術
者って優秀なヤツばっかりだよね」みたいな寝言を言ってられる訳で（笑）。
みんなもっと、COBOLやJavaに感謝しようよ（笑）。
Re:Java屋なんですが・・・ (スコア:1, 興味深い)
Re:Java屋なんですが・・・ (スコア:1, すばらしい洞察)
Re:Java屋なんですが・・・ (スコア:1)
脳がロジカルなんで、どんな言語だって書いちゃうよ～
な勢い。
仕様書の存在こそが問題 (スコア:4, すばらしい洞察)
問題はそれらが無い場合。
リプレースしようとするとまずCOBOLが読めないとお話にならない。
なのでコボラーが生き残ってるうちにドキュメントをきっちり作らせておくべきでしょうね。
それか、要求仕様から作り直すか。
考えようによってはこちらの方が傷が浅くて済むかもしれません。
# 「COBOL→Xなトランスレーター」ってのも考えたんだけど、
# そんなものが吐いたコードを保守させられる状況を想像したら
# この世の地獄以外の何物でもなかったので。
Re:仕様書の存在こそが問題 (スコア:2, すばらしい洞察)
Re:仕様書の存在こそが問題 (スコア:2, 興味深い)
コボラーが書く仕様書は、COBOL色の強い(COBOLのコードに直接変換可能な)ものになる気がします。
COBOL のソースコードがあればね (スコア:1, 興味深い)
Re:仕様書の存在こそが問題 (スコア:3, おもしろおかしい)
CODASYL乙
# フレームの元
Re:仕様書の存在こそが問題 (スコア:3, すばらしい洞察)
そこに実装されているアルゴリズムが何であるかを理解することは、
かなり異なります。
特に、メモリ制約がきつかった昔に作られたプログラムは、
データ表現が無理やり切り詰められていたりするので、
その手のノウハウを知らないと、理解するのはつらいのでは？
Re:仕様書の存在こそが問題 (スコア:4, 興味深い)
それは『後年の』COBOLであって、ホンモノ（cobol60）だとマシン依存が山ほどあったぞ。
# リンケージセクションが１ページ(4096バイト)しか使えない仕様に泣いた...
notice : I ignore an anonymous contribution.
Re:仕様書の存在こそが問題 (スコア:2, すばらしい洞察)
performの使い方、意味が判らない人とか多いでしょう。
while,for,gosubの合成ですしね。
data divisionの理解とか、ちょっと面倒かも。
「redefineって意味がわかんね」的な人も多いのではないかと思います。
あとOCCURS句とか。
データ定義が繰り返される事に違和感を感じる人は多いのではないかと思います。
high-valueとかlow-valueの代わりになる値とかどうするんだろうとか思うし。
ま、知らない人が理解するのに時間がかからないでしょうが。
使い捨ての技術を覚えるなんて不幸な仕事、喜んで受けてくれる人も少ないでしょうね。
Re:仕様書の存在こそが問題 (スコア:3, おもしろおかしい)
防御線を張っているのです。
現役 (スコア:4, 興味深い)
なんだかんだ言われますが、よほどのことがない限りCとかJAVAより後世に残る気もします。負債なのは確かですが。
未来はないけど食ってはいける？
ちなみに同期の友人はPL/Iを…
Re:現役 (スコア:1)
Re:現役 (スコア:2, 参考になる)
Re:現役 (スコア:1, 興味深い)
地方自治体ではまだまだ現役ですね。今後も当分は現役でしょう。
うちの会社は実質三セクなので、
お役所にシステムを作り直す余裕が生まれるまでは、
COBOL仕事が途切れることはなさそうです。
＃そんな余裕が生まれる見通しは今のところゼロ。
一から作り直せば？ (スコア:3, 興味深い)
ここを無理やりCOBOLシステムとの併用→切り替えみたいな事するから、
大惨事になる訳で。メインフレームからWS COBOLへの移行なんてムリ筋
としか言えないと思うんですが。
そりゃ、ケースバイケース、保守部品かき集めて、ぶっ倒れるまで使い
続けた方がいい場合もあるんでしょうけどね。「COBOLコードの近代化」
なんてのは正気の沙汰ではないですよ（ところでオブジェクトコボルなん
て誰が使ってるんですか？）
それにしても、そう遠くない将来、「えっ！？JAVAだって、そんな古臭
い言語もう誰も使ってないですよ…」「いやだなぁ、Javaラーは考えが
古臭くて…」「時代遅れのJavaコードをどう近代化するか？」なんて言
われるようになるんですかね？恐ろしい…
Re:一から作り直せば？ (スコア:2, すばらしい洞察)
Re:一から作り直せば？ (スコア:2)
2000億行の 百分の１ で済むのでは、ちゃんと設計すると。
ゴミの書き換えなんて、ばかばかしい。
様々な原因で 「水増し」されたソースが主成分なので、
水増しの要因
１．死んだ、生きているか死んでいるか不明な ソース
２．コピペで N倍になったソース
３．新設計で M分の１になる ソース
Re:一から作り直せば？ (スコア:1)
COBOL時代に作られたシステムなんて相当長い間動いてるわけで、その間要件変更とか機能拡張なんが多数行われてつぎはぎだらけの構造になってる確率が非常に高い。
そういうシステムで言語変更レベルの大手術をするなら、ついでに基本要件から見直してシステムを再構築したほうが短期間でいいものができるんでない？
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:一から作り直せば？ (スコア:4, すばらしい洞察)
「これまで通り」が使えないわけですから。
Re:一から作り直せば？ (スコア:1)
使わないマシンを保守しておいたり、
出向先で定年迎えたおじいちゃんを呼び戻すなんて
やりたくはない。
しかし、人の登らぬ山にこそ宝があるのも事実なのです。
そんな場合に (スコア:3, 参考になる)
簡単だけど難しい方法 (スコア:2, すばらしい洞察)
難点:彼らはCOBOL以外でもCOBOL風コードを書く
# マジでお願いします
Re:簡単だけど難しい方法 (スコア:3, おもしろおかしい)
あるRDBMSを使った環境に移植された元COBOLプログラム。テーブル定義を見ると「data varchar2(1024)」の列が一つだけ。そしてプログラムの側には、その「レコード」を構造体で分割して処理するコードが見つかった。
あぁ、DATA DIVISIONの名残がこんなところに…… orz
Re:簡単だけど難しい方法 (スコア:1)
全件読んでキーブレイクするコード書くんじゃねぇ
Re:簡単だけど難しい方法 (スコア:1, すばらしい洞察)
BASIC(非VB)やってた奴が書いたVBなんてモロそれだし。
Java臭い○○(お好きな言語をどうぞ)とか枚挙に暇がない。
どんな言語でもそれらしく書ける人なんて、そうゴロゴロといるわけじゃない。
Re:簡単だけど難しい方法 (スコア:1, おもしろおかしい)
# やぁ、関数型言語に感化されて
言語云々以前に (スコア:2, 興味深い)
気にも留めずに使っているそれらの多くは詳細が非公開で互換性に関して保障され続けるわけではない。
むしろ、存在そのものが無くなる可能性もあるわけで。
そのような基幹システムが20年30年の時間の流れに抵抗できるかが正直判らないです。
最終的には仮想技術使って単独環境にしてどうにかする事になると思うけど・・・
#オプソス信者ではないけどね。
#あと何か偉そうな事いってるのでAC
アセンブリコードで動く (スコア:2, 参考になる)
今、動いている COBOL プログラムは安定して動いているので、特にメンテナンスする必要もなかったりするのではないか。（わからないけど）触ると壊れるようなコードなので、誰も触れないとか。
＃書いてる内容は無責任だけど、もともと無責任なので、ID
COBOLを勉強すればいいような (スコア:2, すばらしい洞察)
仕事なので新人に「覚えろ」って言えばいいだけのような。
他の言語解っていれば難しいこととは思えません。
逆に「次世代言語COBOL！」とかCOBOLを知らない若者に覚えさせるとか。
#他の人が使えない言語を使えるって、作業単価高くなると思うんだけどナー
Re:COBOLを勉強すればいいような (スコア:2, おもしろおかしい)
COBOL の刑に処す！刑期、12年。
あれ、別に娑婆にいても何も変わらないんじゃ…
既得権益化 (スコア:2, すばらしい洞察)
やってることは他と変わらない陳腐なメンテナンスや維持だけど、
銀行なんかではびっくりするほど高給の人もいますし、定年まで純粋な技術屋を続けることができます。
で、他言語や新技術に移行しようとすると、既得権益を確立したその人達が強行に拒絶するケースが少なくないです。
一般のIT業界ならあっという間に切り捨てられるぐらい質が悪く高齢なのが露呈してしまいますから。
移行がちっとも進まずに、依然COBOLが使われている理由の１つです。
業界関係者なのでAC
謎のマスターファイル類のDB化(核爆) (スコア:1, 興味深い)
下にも無いのに糸色望した！(どっちがどっちのパクリまでなんマイル？)
"castigat ridendo mores" "Saxum volutum non obducitur musco"
Re:謎のマスターファイル類のDB化(核爆) (スコア:5, おもしろおかしい)
COBOLの延命の為に (スコア:1)
冷凍保存とか。
#改造したいときには起こしてください。
Re:弊社の方針 (スコア:2, すばらしい洞察)
分かってないのはあーた (スコア:5, 興味深い)
COBOLという言語自体には大きな問題が無いってのいいとして, 本当に問題なのは分からなければならないデータフォーマットが処理に依存して設計されているということ. この処理中心設計というやつがコンピュータの性能が低かった1980年代前半ぐらいまでははびこっていて, しかも大規模なシステムほどそれ以前からの歴史を持っているため重荷になっているんですよ. すなわちデータだけではデータの意味は分からず, プログラムを伴って初めてデータフォーマットやそこに格納されているデータの意味が明かになるというのがレガシーシステムの問題の本質です.
これらのデータフォーマットはその当時の段階でもビジネスロジックと処理ロジックのキメラみたいな存在だったわけですが, そこに木に竹をつぐような塩梅で新しいロジックやデータを追加していったものだから…
データ構造とロジックの分離というのが実用的に広まりはじめたのが, おおよそ今から20年前ぐらいで, このぐらいからクライアント-サーバシステムとかでクライアント側ではBASICやC, ホスト側でも生産性の高い第四世代言語とか構造化COBOLが使われはじめました. そのため本当に酷いレガシーシステムというと必然的にCOBOLということになってしまったんだと思います.
レガシー？ (スコア:2, 興味深い)
Re:負の遺産ってねぇ、あーた (スコア:1, すばらしい洞察)
プログラムを使うという事は入力に対して何らかの処理をした結果の出力も求められる。
正しい欠落のない仕様書がすべて残っていればそれが使えるだろう。
だが仕様書が正しいのかを確認するためにはプログラムが読めなければならない。
そして仕様書が失われていたり差異があった場合は真のロジックはプログラムの中に組み込まれている。
Re:負の遺産ってねぇ、あーた (スコア:2, すばらしい洞察)
データというか
データ構造および構造各要素(RDBならテーブルとかカラムとか)の命名から
「素直に」読み取れる範囲のことだけをしてるのならば、
データ構造だけ見せてくれれば判る、
という某御大の言葉どおりのシステムになる。
が、
実際の多数の現場では、DQNな連中が、
そういう判りやすいかたちをわざわざ捨ててしまい、
処理ロジックのほうで複雑怪奇なことをやってしまい、
それをデータ構造の素直さに反映するっていう工程を怠り、
結果、処理を読まないと何も判らないシステムを
作ってしまう。
それはあくまで人災なんですよ。
DOAとやらの肩を持つ気は無いけど、
少なくとも「データ構造で出来るだけ素直に、システムのかたちを表現しよう」
っていう姿勢は、重要だ。
なぜならそのほうが判りやすいからだ。
「うごき」で表現するより「かたち」で表現するほうが、
人間にとっては判り易いのだよ。
逆にいえば、そういう「判りやすくする化」の工程をサボるのが
得てして有り勝ちな(DQNな)現場だ。
Re:負の遺産ってねぇ、あーた (スコア:1)
Re:負の遺産ってねぇ、あーた (スコア:1)
データベースは詳しくないのだけど、データとロジックを簡単に分けられないというか、RDBならば表（データ）の設計の時にやることとがいちいちロジックで書かれているので大変なのではないですか。
今のようにRDBが普及していれば、仮にDBMSを使わなくても、正規形はどうだとか、どういうのが良いデータの構造なのかとか考えながら作ると思うけど、そのような予備知識も無くて作っていて、同じようなデータがプログラムのあちこちにあるとか、わずかな実行時間の節約のために変な参照をしているとかは考えるだけで憂鬱になります。
Re:負の遺産ってねぇ、あーた (スコア:2, 興味深い)
＞RDBMSだのWebサービスだのP2Pだの、全てが負の遺産になってると思うけどな
残念ながら同意します。
一応、ソフトウェアの負の遺産化の一因が、放置しすぎて「ソフトウェアが死ぬ」ことである
という主張もあり、一理あります。テストコードを書き、ちゃんとメンテしていれば
ソフトウェアは生き残るのかもしれません。
でもそれは（COBOLでも成立するはずの）理想論です。
私はソフトウェアの劣化は、究極的にはデータ構造やプログラム言語の問題ではなく、
プログラマが人間である以上絶対に避けられない人間としての限界を
抱えているが故の問題だと考えます。
たとえばプログラマが読んで頭の中に安全に展開できるコード行数は、
数十年前からほとんど変わっていません。
＃その証拠に、「バグはコード行数に比例する」とトム・デマルコ氏も言ってます。
実際、コンピュータの性能向上ペースとモニタの大型化のペースには、驚くほどの差が
あります。明らかに、コンピュータは進歩しているのに、人間（含むHuman I/F）は
それほど進歩していません。
言い換えるなら、人間は自身の性能向上にあまりにも無関心なのです。
この人間側の限界故に、ソフトウェア（の成長・複雑化）は、遅かれ早かれ
人間の理解力を超える（＝負の遺産化）という結果になります。
言語がどれだけ高機能化しても無駄です。制約はソフトウェアの側には無いのです。
私は、もし技術的にこの問題を解決しうる方法があるとすれば、
それはコードの善し悪し（の解析結果）を、単純に「画像の美醜」として
一般人でも判断できるレベルにまで変換することだと思います。
詳細仕様書より一段下、コードレビューより一段上あたりに、
コード評価技術や可視化技術を駆使した視覚的なレビュー階層を導入する形です。
「この青く光っている部分は安定している。この部分のコードは信頼できる」
「この黄色と紫と赤が混ざった部分はグロテスクで危険だ。
直さないとどんどん危険が増えていく。とにかく最優先で直すんだ」
自分でも、なんと人間を馬鹿にした意見なのだろうとは思いますが、
少なくともここまでやらないとソフトウェアの負の遺産化は
食い止められないでしょう。
腐っているか否かを誰もが理解できることが、ソフトウェアが生き残れる
条件だと思うのです。
＃長文におつきあいいただきありがとうございます
Re:「近代化」しなくていい (スコア:2, 興味深い)
Perlと(Visual?)BASICの違いは、「職業プログラマの多さ」だと思います。
で、「コボラー＝ダサい」も同じアルゴリズムではないかと。コンピュータを好きではない、職業としてのみのプログラマは、「必要に迫られてやむなく覚えたこと」以外のコンピュータの使い方を覚えようとしません。
コボラーではありませんが、RPGという言語の開発者の中には、「黒い画面(端末エミュ)を立ち上げてくれないと、Windowsが使えない」というご年配の方が結構いらっしゃいました。
そう言った意味で言うと、趣味やハッカーの言語であるPerlより、基幹業務システムの開発に使われやすいVBの方が、上記職業人に連想されやすく「＝ダサい」と繋がりやすいのではないでしょうか?
事態は際限なく悪化する。