不具合が最も多いのは Java アプリケーション、少ないのは COBOL 82
ストーリー by reo
どっこい生きてる 部門より
どっこい生きてる 部門より
cheez 曰く、
ソフトウェアクオリティツールのメーカーである Cast Software が行った分析によると、プログラムに不備が最も多い言語は Java だそうだ (Computerworld の記事、本家 /. 記事より) 。
同社は 10 以上の業界の 160 社で使われている 745 のアプリケーション、行数にして 3.65 億行に渡るコードを分析したとのこと。Java EE、COBOL、.Net、C、C++ などで書かれたこれらのアプリケーションから 1,800 種に及ぶ開発不備を探しだし、修正に要するコストを算出したところ、Java EE のアプリケーションが最も不備が多く、コード 1 行あたりの単価は 5.42 ドルであるという結果となった。反対に最も安いのは COBOL であり、コード 1 行あたり 1.26 ドルであると算出された。
同社にてチーフサイエンティストを務める Bill Curtis 曰く、Cobol の場合は 30 年以上に渡り手が入れられ続けており、最も重篤な問題は長い年月の間に既に修正されてきたと考えられるという。一方 Java に関しては、参入してくる人々が必ずしもコンピュータサイエンスに強いとは限らず、ソフトウェアエンジニアリングに詳しくない人々によってプログラムが書かれている現状が影響しているのではないかと予想しているそうだ。
technical debt (スコア:3)
元記事が technical debt という観点で書かれているのは非常に興味深い点です。
http://ja.wikipedia.org/wiki/%E6%8A%80%E8%A1%93%E7%9A%84%E8%B2%A0%E5%82%B5 [wikipedia.org]
# ちなみに私が「技術的負債」という概念を初めて知ったのはジョエル・スポルスキのブログ(復活熱望)からでした。
この言葉を使えばITに疎い経営者にも、安易な実装の危険さを理解してもらえたので、
ぜひぜひこの言葉・概念を広めて、当たり前のように誰もが知るようになってほしいですね。
ただバランスシートの見方を知る人には効果があるものの、そうでない人にはあまり効かないのが困り物。
できる営業(金銭感覚が鋭い人)には通じてもダメ営業には(どんな例えをしても)通じないから意味が無いっていうのが最大の弱点ですかね。
つまり (スコア:2)
Javaよりも.Netの方が良いって事なのカナ、事なのカナ？
Re: (スコア:0)
2回言うな！
Re: (スコア:0)
嘘だっ！！！
Re: (スコア:0)
Re: (スコア:0)
調査結果の両端を例に上げてるだけなんだぞっっっっ！！
正直、なんとでも解釈できる調査結果なので、こんなんを記事にされても…としか思えないんだぞっっっっっ！！
減点法評価のたまもの (スコア:2)
減点法で評価を行うと、
最も仕事をしていない人が、高得点になります。
だから、お役人は仕事しないのです。
Web系は? (スコア:1)
あまり詳しくない人が今いちばん投入されてる言語って、Javascript, PHPあたりだと思ったんだが、案外そうでもないのかなぁ。
1を聞いて0を知れ!
Re: (スコア:0)
新人が多いという可能性は高いでしょう。
学校で学んだだけ、実務経験無しでも、とりあえずソース書ければ投入されるってことも多いだろうから
Cobolのように新しい人が少なければ、ベテランの割合がその分高くなるので、相対的に不具合は減るでしょうね。
Re:Web系は? (スコア:1)
Re:Web系は? (スコア:2)
安いのはコストで単価じゃないのでは？
仮に単価が高くても工数が少なければコストは抑えられる
#存在自体がホラー
Re:Web系は? (スコア:1)
つまり、Web系は間違いは多いかもしれんけど、クリティカルなものを扱わないから間違えたときの被害は少ない、ということ?
1を聞いて0を知れ!
此処までVBなし (スコア:1)
あとオブジェクト指向言語はデバッグが大変だから、
COBOLみたいな単純な手続型言語だと同じ行数のｺｰﾄﾞに対するテスト時間が大幅に少ないとか？
＃Javaだとコード自体に問題が無くてもランタイムのせいでバグったりするから・・・と思ったらそれはVBでも同じかｗ
Re: (スコア:0)
どっちかというとCOBOLだと潜在バグを残しづらいって事かもしれません。
イベント発生型の場合は条件を網羅するだけで大変だったりしますし。
メモリ不足で自動開放されるまでなら発生しないとかわかりづらいです
Re: (スコア:0)
Re: (スコア:0)
パンチカード読み込んで帳票処理やってラインプリンタで出力してデータをMT保管出来れば良かった時代の言語だから、
デバッグに四苦八苦するような複雑怪奇な機能はないし、よもともと複雑怪奇なアプリケーション作るのには使われてませんよ
（COBOLのオバちゃま談）
Re:此処までVBなし (スコア:1)
Re: (スコア:0)
>＃Javaだとコード自体に問題が無くてもランタイムのせいでバグったりするから・・・と思ったらそれはVBでも同じかｗ
それってJavaの不具合ですよね
>単純にCOBOLの開発なんて主にコピペだから不具合が起こりにくいだけという気が・・・
極論すればコードを使い回せるってライブラリと同じですよね
ソースで使い回すか、オブジェクト形式で使い回すかの違い
>COBOLみたいな単純な手続型言語だと同じ行数のｺｰﾄﾞに対するテスト時間が大幅に少ないとか？
単純てすばらしいですよね
Meft&ProCOBOLの組み合わせでシステム開発していますが、
ライブラリやコンパイラも含めてCOBOLのバグに遭遇したことは有りません
ORACLEは4回くらいパッチ当てましたけど
一方Javaで開発しているプロジェクトをみると文字コードやJDBCですごくハマってました
Re: (スコア:0)
私は毎年２，３件、COBOLのバグに遭遇しているのだけど……
コード、コード、コード (スコア:1)
>同社は 10 以上の業界の 160 社で使われている 745 のアプリケーション、行数
>にして 3.65 億行に渡るコードを分析したとのこと。
分析したというか、Cast Software社のこれまでやってきた業務からの
集計じゃないのかな。
でもこれだけのコードを入手しても、秘密保持契約を結んでるだろうから
そのうちの優れたコードを自社で開発するソフトに流用することはできないと。
残念だろうな。
-- う～ん、バッドノウハウ？
例えば、Javaを避ける (スコア:0)
> 一方 Java に関しては、参入してくる人々が必ずしもコンピュータサイエンスに強いとは限らず、ソフトウェアエンジニアリングに詳しくない人々によってプログラムが書かれている現状が影響しているのではないかと予想しているそうだ。
それって言語の責任なの?
素人には使い始めることすらできなくて、残念なプロジェクトでは選定の対象にすら上がらないように言語を設計しろってこと?
Re:例えば、Javaを避ける (スコア:2, 興味深い)
Re:例えば、Javaを避ける (スコア:2)
誰も良いとか悪いとかは言っていないと思います。
調査をしてデータが出て、それをどう読み取るかの部分で、利用者層の偏りという予想がなされたというだけの話です。
そして妥当な予想だと思いますよ。
Re: (スコア:0)
＞それって言語の責任なの?
そんな話じゃないでしょ。
Re: (スコア:0)
稼働年数 (スコア:0)
今稼動しているアプリケーションの分析を行うと、稼働時間の長いアプリケーションの不具合はが正されて少なくなっているのでは？
だから、COBOLが少ないんじゃないの？
Re:稼働年数 (スコア:1)
加えて、COBOLで不具合の多いアプリケーションが廃棄されたることで、不具合の多いCOBOLアプリの
カウントが下がり、COBOLで変更の多いアプリケーションはJavaに移植されたり（そしてCOBOLプログラムの
不具合もそのまま移植されたり）して、不具合の多いJavaアプリのカウントを増やしているのでは。
Re: (スコア:0)
君はまずタレコミを最後まで読もうな。リンク先まで読むなんて無理難題は要求しないであげるから。
Re: (スコア:0)
COBOLの場合、新規案件ってあるのかな?
新規で基幹システムを作る場合COBOLではなくてC系言語やネットワークならJavaで作る気もするし
今更、COBOL使うメリットってあるのかな?
想定の範囲内 (スコア:0)
web系といったらとりあえずjavaで～、みたいなのが一時期流行り
それのメンテや拡張で新人が駆りだされまくり、残ったのはごみの山、という話？
まあそれが言語の良し悪しには繋がらないけどね
＃多分いまでもなんだかんだでstrutsが一番多く使われていると思う
Re: (スコア:0)
保守案件がstrutsなのは仕方ないと思うが、新規でもstrutsだらけなのは泣ける。
Re: (スコア:0)
新規案件ならRailsかCakeかASP.NET MVCのどれかだよね
Struts2なんてなかった
定石 (スコア:0)
まだSQLがまともに使えなかった時代のCOBOLでは定石と呼べる物があり、
それが普通に実装されていた気がする。
先輩達のソースでよく勉強した記憶があるな。
他の言語でそんな印象を持った事が無い。
もちろん現場毎のルールを感じる事は有っても、
言語からそれを感じる事は無いな。
Re: (スコア:0)
つ Python
Re: (スコア:0)
と、いうのがJavaが置かれた現実なんだよね。
Javaにも定石はあるんだけどね。
他の言語は微妙。
Rubyはもしかしたらないかもしれないと思わせる。
Pythonはあるかな？
C#もJavaと同じ定石でいけると思う。
PHPは知らない。
Javaだとデザインパターン (スコア:0)
Java・・・に限った話でも無いですが、オブジェクト指向中心の言語だと デザインパターン [wikipedia.org]の類が定石に当たるかと思います。
世の中には、それすら意識していない糞ソースが溢れており、感じる事は無いと言われてしまっても正直仕方ない状況だとも思いますが。
＃
統計の嘘 (スコア:0)
実はCOBOLのコードは、延々と続く宣言文とか、既存コードのコピペばっかりで、
コード行数に比べて、新規開発行数がすごく少ないってだけじゃないかって気が。
#Javaのコード密度がそれほど高いとも思えませんが、まあCOBOLに比べれば…だいぶ…
Re:統計の嘘 (スコア:1)
アホみたいにずらずら書かれた、ただ値を入れて返すだけのどうでもいいgetter/setterが激しくコードの密度を下げてる気がします。
Re:統計の嘘 (スコア:1)
20年以上前から, DATA DIVISIONさえなければCOBOLでプログラム書いてもいいって人は多かったですからね. 1人1台のPCがあるって時代でもないので, コピペもできずに写経のごとく延々と手書きするのは苦行でしかなかったです.
# 自前のPCで早々と手書きコーディングから解脱したけど
Re:統計の嘘 (スコア:1)
そんなソースは、単独では訳が分かりません。
じゃあCobolで新プロジェクト始めたら崩壊ですね (スコア:0)
枯れたコードが多い少ないとか、ベテランが多い素人が多いだけの話で片付くようじゃずいぶんと後ろ向きだと思うんですね。だって、この記事を真に受けて「じゃあCobolやりましょう」ってCobolを書く新人を増やして、Cobolで新たなプロジェクトをゼロから始めたらあっさりこの前提は崩れてしまいます。
昔書かれて、2000年問題を乗り越えて、バグを徹底的につぶしきった枯れたコードが多いからというのは、枯れてないコードが新たに複数作られるだけであっさり崩壊です。それを書くのがベテランでなく新人であればなおのことミスも多いでしょうし。
であればJavaは今一番元気で参入者も多く新プロジェクトも作られ続けている言語であるとも言えてしまい、Cobolが不活性な言語であるというのも含めて、もし記事の趣旨がJavaたたきやCobol持ち上げなら皮肉な結論になってしまいますね。
# 「目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond」と/.Jの一番下にちょうど出てました
Re:じゃあCobolで新プロジェクト始めたら崩壊ですね (スコア:1)
なるほど、いつも節穴の数だけ揃うのが問題だったのか（違
------------
惑星ケイロンまであと何マイル？
Re:じゃあCobolで新プロジェクト始めたら崩壊ですね (スコア:1)
ただ、常に十分な数の目玉を揃えられないのは深刻な問題だ。
いや、本当にそういう意味かもね。
#存在自体がホラー
Re:じゃあCobolで新プロジェクト始めたら崩壊ですね (スコア:1)
ℵ1は必要ないけどℵ0は必要だとか.
単純な比較は意味が無い (スコア:0)
じゃあ、COBOLでWebサービスの実装するとして、
同じサービスを実装するのに必要な行数はどうなるのかな？
もういい加減、ステップ数を基準にするのはやめたほうが良い。
少なくとも異なる言語では。
Re:単純な比較は意味が無い (スコア:1)
「同様のプログラム作成をする際、平均化するとどの言語でも同程度の不具合が見つかる」と仮定すると
「JAVAが最もステップ数濃縮に優れていて、COBOLが最も冗長だ」という結論も導ける、と。
Javaもない昔はねえ (スコア:0)
言語仕様そのものの出来不出来の他に、言語処理系とかの問題もあるわけで。
K&R位しか参考書がなかった頃、C言語でプログラミングをしてデバグをやったものの、自分が書いたコードに問題があるのか、コンパイラにバグがあるのかが判らんなんてことが多々あって。
COBOLなら、コンパイラのバグで悩むことはないのにと思ったもんです。
統計みて (スコア:0)
飛行機の被弾の話を思い浮かべたが……はて。
COBOLねぇ (スコア:0)
単純にやれること少ないし、決まりきった単純なこと（10進演算と帳票出力くらい？）しか
しないから、バグも少ないって話なんじゃないですかね。
メモリ動的に確保できないしハッシュすらないし（あるの？）、
ちょっとでも複雑なものをCOBOLで作ろうなんて人いないでしょう。
Re:COBOLねぇ (スコア:2)
UI系も「利用者がそんなことしちゃったか… 想定外！」みたいなことばかり。
そりゃ、しっかりと想定した流れで入力してくれるCOBOL時代とは土俵が違うわ。