パスワードを忘れた? アカウント作成
990783 story
バグ

不具合が最も多いのは 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 に関しては、参入してくる人々が必ずしもコンピュータサイエンスに強いとは限らず、ソフトウェアエンジニアリングに詳しくない人々によってプログラムが書かれている現状が影響しているのではないかと予想しているそうだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by ikotom (20155) on 2011年12月13日 13時21分 (#2065747)

    元記事が 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に疎い経営者にも、安易な実装の危険さを理解してもらえたので、
    ぜひぜひこの言葉・概念を広めて、当たり前のように誰もが知るようになってほしいですね。

    ただバランスシートの見方を知る人には効果があるものの、そうでない人にはあまり効かないのが困り物。
    できる営業(金銭感覚が鋭い人)には通じてもダメ営業には(どんな例えをしても)通じないから意味が無いっていうのが最大の弱点ですかね。

  • by miyuri (33181) on 2011年12月13日 11時58分 (#2065681) 日記

    Javaよりも.Netの方が良いって事なのカナ、事なのカナ?

    • by Anonymous Coward

      2回言うな!

    • by Anonymous Coward

      嘘だっ!!!

    • by Anonymous Coward
      .Net利用者が少ないだけでは。
    • by Anonymous Coward

      調査結果の両端を例に上げてるだけなんだぞっっっっ!!

      正直、なんとでも解釈できる調査結果なので、こんなんを記事にされても…としか思えないんだぞっっっっっ!!

  • by reininn (35924) on 2011年12月13日 17時08分 (#2065872)
    この様に
    減点法で評価を行うと、
    最も仕事をしていない人が、高得点になります。
    だから、お役人は仕事しないのです。
  • by greentea (17971) on 2011年12月13日 11時45分 (#2065670) 日記

    あまり詳しくない人が今いちばん投入されてる言語って、Javascript, PHPあたりだと思ったんだが、案外そうでもないのかなぁ。

    --
    1を聞いて0を知れ!
    • by Anonymous Coward

      新人が多いという可能性は高いでしょう。
      学校で学んだだけ、実務経験無しでも、とりあえずソース書ければ投入されるってことも多いだろうから

      Cobolのように新しい人が少なければ、ベテランの割合がその分高くなるので、相対的に不具合は減るでしょうね。

  • by duenmynoth (34577) on 2011年12月13日 12時11分 (#2065697) 日記
    単純にCOBOLの開発なんて主にコピペだから不具合が起こりにくいだけという気が・・・
    あとオブジェクト指向言語はデバッグが大変だから、
    COBOLみたいな単純な手続型言語だと同じ行数のコードに対するテスト時間が大幅に少ないとか?

    #Javaだとコード自体に問題が無くてもランタイムのせいでバグったりするから・・・と思ったらそれはVBでも同じかw
    • by Anonymous Coward

      どっちかというとCOBOLだと潜在バグを残しづらいって事かもしれません。
      イベント発生型の場合は条件を網羅するだけで大変だったりしますし。
      メモリ不足で自動開放されるまでなら発生しないとかわかりづらいです

    • by Anonymous Coward
      デバッグが大変な言語自体が問題ですねw
    • by Anonymous Coward

      パンチカード読み込んで帳票処理やってラインプリンタで出力してデータをMT保管出来れば良かった時代の言語だから、
      デバッグに四苦八苦するような複雑怪奇な機能はないし、よもともと複雑怪奇なアプリケーション作るのには使われてませんよ
      (COBOLのオバちゃま談)

    • by Anonymous Coward

      >#Javaだとコード自体に問題が無くてもランタイムのせいでバグったりするから・・・と思ったらそれはVBでも同じかw
      それってJavaの不具合ですよね
      >単純にCOBOLの開発なんて主にコピペだから不具合が起こりにくいだけという気が・・・
      極論すればコードを使い回せるってライブラリと同じですよね
      ソースで使い回すか、オブジェクト形式で使い回すかの違い
      >COBOLみたいな単純な手続型言語だと同じ行数のコードに対するテスト時間が大幅に少ないとか?
      単純てすばらしいですよね
      Meft&ProCOBOLの組み合わせでシステム開発していますが、
      ライブラリやコンパイラも含めてCOBOLのバグに遭遇したことは有りません
      ORACLEは4回くらいパッチ当てましたけど
      一方Javaで開発しているプロジェクトをみると文字コードやJDBCですごくハマってました

      • by Anonymous Coward

        私は毎年2,3件、COBOLのバグに遭遇しているのだけど……

  • >同社は 10 以上の業界の 160 社で使われている 745 のアプリケーション、行数
    >にして 3.65 億行に渡るコードを分析したとのこと。
    分析したというか、Cast Software社のこれまでやってきた業務からの
    集計じゃないのかな。
    でもこれだけのコードを入手しても、秘密保持契約を結んでるだろうから
    そのうちの優れたコードを自社で開発するソフトに流用することはできないと。
    残念だろうな。

    --
    -- う~ん、バッドノウハウ?
  • by Anonymous Coward on 2011年12月13日 11時53分 (#2065674)

    > 一方 Java に関しては、参入してくる人々が必ずしもコンピュータサイエンスに強いとは限らず、ソフトウェアエンジニアリングに詳しくない人々によってプログラムが書かれている現状が影響しているのではないかと予想しているそうだ。
    それって言語の責任なの?
    素人には使い始めることすらできなくて、残念なプロジェクトでは選定の対象にすら上がらないように言語を設計しろってこと?

  • by Anonymous Coward on 2011年12月13日 11時54分 (#2065677)

    今稼動しているアプリケーションの分析を行うと、稼働時間の長いアプリケーションの不具合はが正されて少なくなっているのでは?
    だから、COBOLが少ないんじゃないの?

    • by firewheel (31280) on 2011年12月13日 20時47分 (#2065963)

      加えて、COBOLで不具合の多いアプリケーションが廃棄されたることで、不具合の多いCOBOLアプリの
      カウントが下がり、COBOLで変更の多いアプリケーションはJavaに移植されたり(そしてCOBOLプログラムの
      不具合もそのまま移植されたり)して、不具合の多いJavaアプリのカウントを増やしているのでは。

      親コメント
    • by Anonymous Coward

      君はまずタレコミを最後まで読もうな。リンク先まで読むなんて無理難題は要求しないであげるから。

    • by Anonymous Coward

      COBOLの場合、新規案件ってあるのかな?
      新規で基幹システムを作る場合COBOLではなくてC系言語やネットワークならJavaで作る気もするし
      今更、COBOL使うメリットってあるのかな?

  • by Anonymous Coward on 2011年12月13日 11時58分 (#2065682)

    web系といったらとりあえずjavaで~、みたいなのが一時期流行り
    それのメンテや拡張で新人が駆りだされまくり、残ったのはごみの山、という話?
    まあそれが言語の良し悪しには繋がらないけどね

    #多分いまでもなんだかんだでstrutsが一番多く使われていると思う

    • by Anonymous Coward

      保守案件がstrutsなのは仕方ないと思うが、新規でもstrutsだらけなのは泣ける。

      • by Anonymous Coward

        新規案件ならRailsかCakeかASP.NET MVCのどれかだよね
        Struts2なんてなかった

  • by Anonymous Coward on 2011年12月13日 12時01分 (#2065685)

    まだSQLがまともに使えなかった時代のCOBOLでは定石と呼べる物があり、
    それが普通に実装されていた気がする。
    先輩達のソースでよく勉強した記憶があるな。

    他の言語でそんな印象を持った事が無い。
    もちろん現場毎のルールを感じる事は有っても、
    言語からそれを感じる事は無いな。

    • by Anonymous Coward

      つ Python

    • by Anonymous Coward

      と、いうのがJavaが置かれた現実なんだよね。
      Javaにも定石はあるんだけどね。
      他の言語は微妙。

      Rubyはもしかしたらないかもしれないと思わせる。
      Pythonはあるかな?
      C#もJavaと同じ定石でいけると思う。
      PHPは知らない。

      • Java・・・に限った話でも無いですが、オブジェクト指向中心の言語だと デザインパターン [wikipedia.org]の類が定石に当たるかと思います。
        世の中には、それすら意識していない糞ソースが溢れており、感じる事は無いと言われてしまっても正直仕方ない状況だとも思いますが。

  • by Anonymous Coward on 2011年12月13日 12時01分 (#2065686)

    実はCOBOLのコードは、延々と続く宣言文とか、既存コードのコピペばっかりで、
    コード行数に比べて、新規開発行数がすごく少ないってだけじゃないかって気が。

    #Javaのコード密度がそれほど高いとも思えませんが、まあCOBOLに比べれば…だいぶ…

    • by Angelica (23122) on 2011年12月13日 12時50分 (#2065720) 日記

      アホみたいにずらずら書かれた、ただ値を入れて返すだけのどうでもいいgetter/setterが激しくコードの密度を下げてる気がします。

      親コメント
    • by SteppingWind (2654) on 2011年12月13日 12時56分 (#2065728)

      20年以上前から, DATA DIVISIONさえなければCOBOLでプログラム書いてもいいって人は多かったですからね. 1人1台のPCがあるって時代でもないので, コピペもできずに写経のごとく延々と手書きするのは苦行でしかなかったです.

      # 自前のPCで早々と手書きコーディングから解脱したけど

      親コメント
    • by wolf03 (39616) on 2011年12月13日 21時53分 (#2065996) 日記
      COPY句でコピペすらあまりない場合もありますね。
      そんなソースは、単独では訳が分かりません。
      親コメント
  • by Anonymous Coward on 2011年12月13日 12時24分 (#2065705)

    枯れたコードが多い少ないとか、ベテランが多い素人が多いだけの話で片付くようじゃずいぶんと後ろ向きだと思うんですね。だって、この記事を真に受けて「じゃあCobolやりましょう」ってCobolを書く新人を増やして、Cobolで新たなプロジェクトをゼロから始めたらあっさりこの前提は崩れてしまいます。
    昔書かれて、2000年問題を乗り越えて、バグを徹底的につぶしきった枯れたコードが多いからというのは、枯れてないコードが新たに複数作られるだけであっさり崩壊です。それを書くのがベテランでなく新人であればなおのことミスも多いでしょうし。

    であればJavaは今一番元気で参入者も多く新プロジェクトも作られ続けている言語であるとも言えてしまい、Cobolが不活性な言語であるというのも含めて、もし記事の趣旨がJavaたたきやCobol持ち上げなら皮肉な結論になってしまいますね。

    # 「目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond」と/.Jの一番下にちょうど出てました

  • by Anonymous Coward on 2011年12月13日 13時05分 (#2065735)

    じゃあ、COBOLでWebサービスの実装するとして、
    同じサービスを実装するのに必要な行数はどうなるのかな?

    もういい加減、ステップ数を基準にするのはやめたほうが良い。
    少なくとも異なる言語では。

  • by Anonymous Coward on 2011年12月13日 13時33分 (#2065755)

    言語仕様そのものの出来不出来の他に、言語処理系とかの問題もあるわけで。

    K&R位しか参考書がなかった頃、C言語でプログラミングをしてデバグをやったものの、自分が書いたコードに問題があるのか、コンパイラにバグがあるのかが判らんなんてことが多々あって。

    COBOLなら、コンパイラのバグで悩むことはないのにと思ったもんです。

  • by Anonymous Coward on 2011年12月13日 14時23分 (#2065790)

    飛行機の被弾の話を思い浮かべたが……はて。

  • by Anonymous Coward on 2011年12月13日 14時23分 (#2065791)

    単純にやれること少ないし、決まりきった単純なこと(10進演算と帳票出力くらい?)しか
    しないから、バグも少ないって話なんじゃないですかね。

    メモリ動的に確保できないしハッシュすらないし(あるの?)、
    ちょっとでも複雑なものをCOBOLで作ろうなんて人いないでしょう。

    • by nabepyu (9623) on 2011年12月13日 16時48分 (#2065861)
      私もそうだと思います。今、求められるプログラムは高度になっています。
      UI系も「利用者がそんなことしちゃったか… 想定外!」みたいなことばかり。
      そりゃ、しっかりと想定した流れで入力してくれるCOBOL時代とは土俵が違うわ。
      親コメント
typodupeerror

コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell

読み込み中...