アカウント名:
パスワード:
流石にここでも飽きられたんじゃないのかと思うがスクラッチで作ろうとしたら失敗した、のほうが興味ひかれてるよ。
そもそもプログラムがCOBOLで書かれている事が問題なのかどうか記事からは判断つかないな。
元々アメリカでは大規模開発はほとんど失敗しているって統計もあったと思うから、別に今回が特別ではないと思うよ。
OSみたいなものは、コード自体は多いかもしれないけど、少数で開発しているので大丈夫ってあったと思う。人が多くなるとダメなんだよね。
解決策も何も・システムのメンテナンスをする体制を整えましょう・複雑な部分は業務も含めて見なおして、見通しを良くしておきましょうという基本的なところを守っておけばこんなことにはならなかったのでは。
今でこそコンピューターシステム構築の基本かもしれないけど、昔はそんなこと考えつきもしなかったわけで。
立派でもなんでもありません。大変なだけです。
やはりCOBOLとCOBOLプログラマーはダメですね。ほれみなさい。こんなクソシステムを作った。迷惑をかけるばかりです。
本当にそれが解決策ならいいんですよ。
ただ完全にそれが嘘なのが問題なんですよ。
インターフェースとか矮小な部分のみに拘泥して、全く解決になっていないのが問題なんですよ。
クソはクソなりに実態あるソリューションなのに、それ以下なのが問題なんですよ。
COBOLでコードを書くからこういう悲劇が起こる。
真面目に返信していいのか迷うが・・・
CだろうとJavaだろうとRubyだろうとScalaだろうとSchemeだろうとドキュメントが無い700万行が問題であって（言語によって同一機能にたいする行数は変わるがおいといて）、COBOLとかどうでもいい話だと思う。
ドキュメントが無くても、もっとましな言語を使っていたら結果は変わっていたかもしれない。グローバル変数の多用はやめましょうとか、大規模でも保守性の高いプログラムを作れる言語的仕組み・慣習・意識がCOBOLという言語、COBOLプログラマーには無い。COBOLもコボラーもKoboもゴミです。
グローバル変数って何でしょうか？
COBOL（少なくともこの場で論じられている様な古いCOBOL）ではパッケージとかプロジェクトとかの概念が無く、1モジュール1exeになる様なオブジェクトモデルで、モジュールレベルを超えた変数は、大記憶に持たせるか、引数で引っ張って来るかしか無いはずです。
グローバル変数って何でしょうか？ ないものの多用なんて出来ないと思います。
でも、大記憶（マスストレージ）と言ったら、ぶっちゃけDBと言っても過言では無いと思いますが、
やっぱりDBはグローバル変数と表裏一体の存在で、テストもしにくくなるし、悪い存在（よく言って必要悪？）だったですか。そうですか。
＃うすうすそうでは無いかと自分も思ってはいました。
COBOLでもCでもJavaでもRubyでもScalaでもSchemeでも無く、他のどの言語でも無く、合意に元づく設計が諸悪の根源の様に思います。
下手に合意をすると、それを根拠にして数千万のサーバーを何台も買ったり（「この合意を実行するためには必要」）されてお客も懲りまくったのかも知れませんが、
本当に合意してくれる範囲が減っています。
そのため、V字モデルの3つの頂点の近傍辺り（合意の取れた仕様と、合意の取れた仕様に直接対応するプログラムの最も基本的な部分と、合意の取れた仕様を検証するシステムテスト）以外は無管理状態になってしまうのが通例です。
JavaならRubyなら合意が取れるか？ オンサイトにお客を常駐させれば合意が取れるか？
さすがに現在では無理かも！！！USは日本より進んでいるので、そういう事態も先に経験しているとか。。
海外COBOLぇ話ですね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
COBOL叩きは飽きられたんじゃないの? (スコア:0)
流石にここでも飽きられたんじゃないのかと思うが
スクラッチで作ろうとしたら失敗した、のほうが興味ひかれてるよ。
Re:COBOL叩きは飽きられたんじゃないの? (スコア:1)
思っていたのですが、確かにアテが外れた印象です。
Re: (スコア:0)
そもそもプログラムがCOBOLで書かれている事が問題なのかどうか記事からは判断つかないな。
Re: (スコア:0)
元々アメリカでは大規模開発はほとんど失敗しているって統計もあったと思うから、別に今回が特別ではないと思うよ。
OSみたいなものは、コード自体は多いかもしれないけど、少数で開発しているので大丈夫ってあったと思う。
人が多くなるとダメなんだよね。
Re: (スコア:0)
解決策も何も
・システムのメンテナンスをする体制を整えましょう
・複雑な部分は業務も含めて見なおして、見通しを良くしておきましょう
という基本的なところを守っておけばこんなことにはならなかったのでは。
Re: (スコア:0)
今でこそコンピューターシステム構築の基本かもしれないけど、昔はそんなこと考えつきもしなかったわけで。
解決策 ＝ COBOLを捨てること (スコア:0)
立派でもなんでもありません。
大変なだけです。
やはりCOBOLとCOBOLプログラマーはダメですね。
ほれみなさい。こんなクソシステムを作った。
迷惑をかけるばかりです。
Re: (スコア:0)
本当にそれが解決策ならいいんですよ。
ただ完全にそれが嘘なのが問題なんですよ。
インターフェースとか矮小な部分のみに拘泥して、
全く解決になっていないのが問題なんですよ。
クソはクソなりに実態あるソリューションなのに、
それ以下なのが問題なんですよ。
Re: (スコア:0)
COBOLでコードを書くからこういう悲劇が起こる。
Re: (スコア:0)
真面目に返信していいのか迷うが・・・
CだろうとJavaだろうとRubyだろうとScalaだろうとSchemeだろうと
ドキュメントが無い700万行が問題であって（言語によって同一機能にたいする行数は変わるがおいといて）、
COBOLとかどうでもいい話だと思う。
Re: (スコア:0)
ドキュメントが無くても、もっとましな言語を使っていたら結果は変わっていたかもしれない。
グローバル変数の多用はやめましょうとか、大規模でも保守性の高いプログラムを作れる言語的仕組み・慣習・意識がCOBOLという言語、COBOLプログラマーには無い。
COBOLもコボラーもKoboもゴミです。
Re: (スコア:0)
グローバル変数って何でしょうか？
COBOL（少なくともこの場で論じられている様な古いCOBOL）ではパッケージとかプロジェクトとかの概念が無く、
1モジュール1exeになる様なオブジェクトモデルで、モジュールレベルを超えた変数は、大記憶に持たせるか、
引数で引っ張って来るかしか無いはずです。
グローバル変数って何でしょうか？ ないものの多用なんて出来ないと思います。
Re: (スコア:0)
で、引数に渡せばいいものすら大記憶に格納している状態の事を言っているのだと思うけど。
あとPERFORMも他言語の関数と異なり変数が保護されない（COBOLの仕様としては当然なのは知ってるけど）。
Re: (スコア:0)
でも、大記憶（マスストレージ）と言ったら、ぶっちゃけDBと言っても過言では無いと思いますが、
やっぱりDBはグローバル変数と表裏一体の存在で、テストもしにくくなるし、悪い存在（よく言って必要悪？）
だったですか。そうですか。
＃うすうすそうでは無いかと自分も思ってはいました。
Re: (スコア:0)
COBOLはファイルがエリアにストンと落ちてくる印象なので一層グローバル変数っぽく感じられるかも？
グローバル変数に近いのはLINKAGE SECTIONですかねぇ。使い方次第だとは思うけど。（ちゃんとサブモジュールから返ってきたら別のエリアに必要な項目だけ項目編集していれば問題はないとは思う）
昔BASICやってた私としてはGOSUBみたいなPERFORMも怖い存在。VBでモジュールの上の方にモジュール内変数がわんさかあるような感じで。
Re: (スコア:0)
COBOLでもCでもJavaでもRubyでもScalaでもSchemeでも無く、
他のどの言語でも無く、
合意に元づく設計が諸悪の根源の様に思います。
下手に合意をすると、それを根拠にして数千万のサーバーを
何台も買ったり（「この合意を実行するためには必要」）されて
お客も懲りまくったのかも知れませんが、
本当に合意してくれる範囲が減っています。
そのため、V字モデルの3つの頂点の近傍辺り（合意の取れた仕様
と、合意の取れた仕様に直接対応するプログラムの最も基本的な
部分と、合意の取れた仕様を検証するシステムテスト）以外は
無管理状態になってしまうのが通例です。
JavaならRubyなら合意が取れるか？ オンサイトにお客を常駐させ
れば合意が取れるか？
さすがに現在では無理かも！！！USは日本より進んでいるので、
そういう事態も先に経験しているとか。。
Re: (スコア:0)
海外COBOLぇ話ですね。