パスワードを忘れた? アカウント作成
289044 story
プログラミング

非オブジェクト指向な「Javaプログラミング能力認定試験」 133

ストーリー by hylom
それならCOBOLでいいじゃん 部門より

あるAnonymous Coward 曰く、

SI業界(日本)のJavaプログラマーにはオブジェクト指向より忍耐力が求められている?」というブログ記事が話題になっている。

Java関連の認定試験の1つに「Javaプログラミング能力認定試験」というものがあるのだが、このWebサイトで公開されている試験サンプルがまるでCOBOLのプログラムのようで、オブジェクト指向的ではない設計になっているらしい。

これを受けて、ブログの筆者は

日本のSI業界でJava PGとして仕事をするためには、オブジェクト指向的にきれいなあるべき姿でコーディングできるスキルではなく、このようにオブジェクト指向をまったく理解していない上流のSEが作成した異常な設計書に忠実にしたがってコードを書き、また、その複雑なスパゲッティコードを長期にわたってメンテナンスする根性と忍耐が最重要のスキルとして試験で試されているということなのかと私は理解しました。

と述べている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • Javaの思想どおり (スコア:4, おもしろおかしい)

    JavaのWORA思想をよく表している、良い問題ではないでしょうか。
    Write Once, RunAway

  • 2級とか3級とかがそういうのを作るから、1級なら直せるだろ?という前提でやっているのかもしれませんね。

    でもって、下手な手入れよりまっさら作り直しがよかんべ、という話になるという、この業界でよくあることではなかろうか?

    • でも現実にそういう傾向あるしなあ。

      ド下手糞にスパゲッティプログラムを作らせて、トラブルが発生したら初心者に
      継ぎ接ぎ修正させて、手遅れになったら上級者を担ぎ出す。

      何か間違ってるだろと。

      親コメント
  • by Anonymous Coward on 2011年01月10日 19時07分 (#1885882)
    どこまでが笑い話・都市伝説なのか良く分からないですが、 C++ なんかは「Cの上位互換」であるからして、 C言語に親しんだ人がオブジェクト指向を取り入れながらやるのに向いている、 なんていう話(デマ?)があって、全然オブジェクト指向ではないものを せっせと書いている場面が多々あるっていうウワサはあったりしますよね。 そういうのと似たような臭いですかね…

    究極的には 「// でコメントアウトできる C」みたいな…
    • 笑い話・都市伝説は「オブジェクト指向」そのものでしょう。
      青い鳥を探すように、「オブジェクト指向」を実現する何かが存在すると信じて、
      当所もなく、幻想を求めて旅を続けるのです。
      親コメント
      • オブジェクト指向というか, 言語を含めたソフトウェア開発技術が役に立たないのは, 現実のボリュームゾーンのプログラマの能力を過剰に高く設定しているからじゃないかと思います. おそらくは

        • 関数/サブルーチンといった処理の抽象化は出来ない
        • 文字・文字列・数字といった具体的でプリミティブなデータ以外は取り扱えない. 表/配列といった目で見えるデータ構造以外は理解できない
        • 名前空間の概念を理解できない

        というのを, 現実のプログラマのレベルとして想定しておかなければならないのでしょう. FizzBuzz問題並みに低レベルだとは私も思うのですが, 最長不倒関数が作成される, ポインタの様なちょっとばかりイマジナリなデータにつまづく人が多い, クラスのメンバを全てpublicにしようとしたり, または個々のメンバ毎にアクセスメソッドを設けようとしたりする, ローカル変数を外部からアクセスできない不便な変数とみなす等々の傍証からすると, それほど間違っていないのではないかと.

        このレベルを前提にしてオブジェクト指向とかを考えてみると, 役に立たないのも当然のような.

        親コメント
        • 昔「オブジェクト指向をマスターするのには3年かかる」と言われたものですが、
          現実には3年もタダ飯食わすわけにはいかず、トレーニングに3ヶ月も割いてくれれば御の字。
          そんな訓練不十分な奴らを使っていかに戦い抜くかを考えるとオブジェクト指向の適用はなかなか難しいですね。
          # 3年というのはデザインパターン出現前の話なので今だともっと短縮できるでしょうが、結局デザインパターンをマスターするのが前提。
          # はたしてデザインパターンをきっちり読破するような勉強熱心なのがどれほどいるやら・・・

          あと、業務プログラムの場合、難しい部分はごく一部で大半はIDEが自動生成したClickイベントのテンプレートに処理を書き込んでいくだけで済むことが多くて、そういう簡単な部分ばかり任されてるとメソッド宣言を自分で書いたことのない奴とか普通にいる。
          そいつらに「処理を分けろ」と言ってもメソッドを自分で宣言する行為の敷居が高いのでなかなか実践してくれないし、分けたとしても慣れてないやつは処理の切り出し方が下手なので再利用性が低く可読性も低いコード片をソース中にまき散らすことになり
          「こんな読みにくくなるだけのことをするんならベタに書いたほうがずっとマシ」
          という結論に落ち着いてしまう。

          # そこで誰かが根気強くフォローする環境であればいいんだけどね
          # 現実にはどこの職場でも有能なやつほど暇ではない
          親コメント
    • 1クラス3000行のプログラムとか・・・JavaでもC++でも、都市伝説では聞いたことがある。
      1クラス1000行のプログラムは、見たことがある。

      上流や、マネージャ/チーフアーキテクトがオブジェクト指向、わかってないんだろうねぇ。
      私は・・・わかっている範囲で使っています(こういう奴が、一番チーフアーキテクトになってはいけない)。

      iPhoneアプリがらみでObjective-C勉強していますが・・・まだまだ修行の身ですね、オブジェクト指向。

      --
      -- gonta --
      "May Macintosh be with you"
      親コメント
  • 言語は関係ない (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2011年01月10日 20時45分 (#1885938)

    能力的に問題のあるものが作れば、どんな言語を使ったって腐れたプログラムしかできない。
    逆にまともな者が作れば、部門名にあるCOBOLだって、無駄な分岐やループのないシンプルで可読性の高いものを作る。
    それだけの話。

    • by firewheel (31280) on 2011年01月11日 0時12分 (#1886002)

      まともな者は、いまさらCOBOLなんて腐れ言語は使わない。

      良い技術者はどんな道具でもそれなりに使いこなすが、
      同時に良い技術者ほど良い道具への拘りも人一倍強くなる。

      親コメント
      • by css (41565) on 2011年01月11日 1時21分 (#1886025)

        匠は道具を選ばないというか、弘法筆を選ばずという面もあるからね。

        >同時に良い技術者ほど良い道具への拘りも人一倍強くなる。

        道具を選ぶというのは、職人レベルだという話もありますね。
        職人でもよい職人は、きっちりと長年使った道具を手入れして、自家薬籠中のモノとします。
        たとえば、よい職人であれば、使える道具で、その道具の最善を引き出しますね。
        徒に拘るのは、職人ではなくて、単なる工具コレクターだという面もあります。

        なので、

        >いまさらCOBOLなんて腐れ言語は使わない。

        は、道具のせいにした、単なる逃げ口上でしかないとも思えます。
        COBOLをきっちり使い切った使い方をして精緻なものを組み上げるでしょうね。
        それが出来ないので使わないということでしたら、それは単なる未熟さだと思いますよ。

        親コメント
        • by sindobook (35700) on 2011年01月11日 9時42分 (#1886093)
          しかし、どの道具を使うかで効率もストレスの度合いも違う
          親コメント
          • by css (41565) on 2011年01月11日 13時55分 (#1886198)

            >しかし、どの道具を使うかで効率もストレスの度合いも違う

            その道具に慣れた職人なら、その道具を使うことはそれほどストレスにもならないし、
            効率もその道具で出せるモノを出すよね?
            慣れていないといったことで、その道具を忌避する職人もいますよね。

            たとえば、丸い溝が彫れるノミを持っていない期間が長い職人は、
            角ノミでも丸い溝を彫れるし、丸ノミを調達してもそれを使いこなせる
            様に時間をかけますよ。

            もちろん、使い物にならない道具もあるでしょうが、道具として廃れるだけでしょうね。
            たとえば、ノミなんかいらないよ、自動工具でなんでも出来るという人もいるでしょうね。
            ノミ使いが自動工具を触っても、出来上がりの品質などについての目はあるので、その自動工具も改善したり、ノミとの併用をするでしょう。

            親コメント
        • Re:言語は関係ない (スコア:1, すばらしい洞察)

          by Anonymous Coward on 2011年01月11日 9時47分 (#1886094)
          弘法は「筆が悪いので良い文が書けない」って手紙を書いてますよ。 いつの世でも、ツールが悪いとろくな仕事はできないよ。
          親コメント
      • Re:言語は関係ない (スコア:2, すばらしい洞察)

        by Anonymous Coward on 2011年01月11日 8時42分 (#1886081)
        > まともな者は、いまさらCOBOLなんて腐れ言語は使わない。

        まともな者(開発者)なら、そのような痴れ言は言わない。

        > 良い技術者はどんな道具でもそれなりに使いこなすが、
        > 同時に良い技術者ほど良い道具への拘りも人一倍強くなる。

        開発言語としてのJavaは悪くないが、開発環境、いや、実行環境
        としてはどうなんだろう?
        普及するのも極めて早かったが、腐っていくのも早いような気がする。
        10年後、20年後に実行環境生き残っているとしたら、Javaではなくて
        COBOLのほうが生き残っているような気がしないでもない。

        現在のCOBOL開発者は、もし10年後にタイムスリップしても同じように
        すぐにプログラムを書けると思うが、Java開発者が10年後にタイムスリップ
        したとしたら、使い物にならないと思う。
        COBOLは10年前も今も10年後もあまり変わらないが、
        Javaは10年前と今は違うし、10年後はさらに違うと思う。
        10年後にJavaがまだ使われていればの話だが。

        そんな不安定な環境が優れている道具となるとは、私ならば言えない。
        優れた道具ほど、長い間使いこまれているというものだ。
        親コメント
        • Re:言語は関係ない (スコア:1, おもしろおかしい)

          by Anonymous Coward on 2011年01月11日 9時36分 (#1886091)

          Java5,6あたりは無くなっていると思いますが、1.4.2なんかはなぜか官公庁で残っているきがしなくもないのは気のせいでしょうか・・・

          親コメント
  • あれおかしいな (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2011年01月10日 22時13分 (#1885971)

    デスマストーリなのに/.Jのアイドルの人がいない…(重連打撃音

  • by MkII (26282) on 2011年01月10日 22時21分 (#1885973)
    求人サイトでSI系検索すると、JAVAプログラマってのが多数あって、
    その内のかなりの数が「何らかのフレームワーク経験者」ってのを期待・歓迎スキルにあげてるんだよね。

    求人と実務が乖離してるって事なのだろうか?
    それとも今酷いんで新しく採る人からはなんとかしよう、という意向なのか。
    • 典型的にはこんな感じかと思います。(ネタのつもりはないです)

      派遣で他社に突っ込まれる。
      フレームワーク使用において実装が必要となる最低限のクラスだけ作成が許されます。
      各メソッドはCOBOL的に実装することが求められます。
      共通処理はモジュール単位でユーティリティクラスを作成してそこに全部ぶち込みます。
      もしどうしても新規クラスが必要な場合はプロパー社員で構成される社内エリート部隊に依頼します。
      ただし依頼には事務的手続きが山ほど必要で、品質は担保されません。
      バグ発生時は修正方法まで報告してもなぜか自分サイドモジュールの障害として計上されます。

      意地でもクラスを作らせないのはオブジェクト指向を理解していない要員の知識にも還元できるからでしょうね。
      結局それをすることにより上級者にも把握が難しくなっているだけだと思いますが。

      親コメント
  • by Anonymous Coward on 2011年01月10日 23時10分 (#1885985)
    このパターンはただ単に既存のシステムの設計書(実コード)を
    JAVAに書き換えただけの物では無いでしょうか、
    私は指定の機能通りに動けば良いという場合が多かったので、
    その都度最も早いであろう方法を取ってます。
    細かい追加や仕様変更が後から増えれば増える程長くなりますので
    当然スパゲッティに近くなります。
    スパゲッティになるであろうコードならば先に判りますので、
    対策はしますね。
  • 私感だけど、
    オブジェクト指向というのは、再利用するライブラリを作成する場合は威力を発揮するのはよく分かる。
    しかし、再利用しない場合は不要だし、多人数で開発する場合は他人とのインタフェース部分だけオブジェクト指向的にすれば十分だと思う。
    他人に見せない内部まで生真面目にオブジェクト指向で作ったら、むしろコードサイズが大きくなり。処理が分散することで、かえって可読性が落ちる。

    • by Anonymous Coward on 2011年01月11日 3時11分 (#1886042)
      昔はオブジェクト指向でコードの再利用を促進して生産性向上というのが盛んに宣伝されたからか、再利用に注目して語られることも多いですが、昨今の現場では結合度が低く凝縮度が高いコードを維持して、仕様変更や拡張などに伴う修正のしやすさ(要するに開放/閉鎖原則)を確保するために用いることが多いですね。

      他人に見せない内部まで生真面目にオブジェクト指向で作ったら、むしろコードサイズが大きくなり。処理が分散することで、かえって可読性が落ちる。

      確かに必要なコーディング量は増える傾向にはあると感じますが、一時的なコーディング量の削減より恒久的な修正のしやすさを優先したほうがよいと思っています。
      可読性に関しては、どういうコード設計になっているかというドキュメントをつけるだけでかなり向上しますよ。

      親コメント
  • インテグレート【integrate】

                [名](スル)統合すること。集約すること。

    via goo辞書 http://dictionary.goo.ne.jp/leaf/jn2/16749/m0u/%E3%82%A4%E3%83%B3%E3%8... [goo.ne.jp]

    ... 知識を集約できてなきゃ違うよな

    # 細かい部分はわからないのはいいけど、その代わりキチンと意見を確認する(その権限があるようにする)じゃないと悲惨だよね

    ...

    こっちの話も思い出した
    http://el.jibun.atmarkit.co.jp/hidemi/2010/12/post-1eb2.html [atmarkit.co.jp]
    http://el.jibun.atmarkit.co.jp/hidemi/2010/12/sepg-43e7.html [atmarkit.co.jp]
    ここではSEの話だけど、

    SE/PGで上下はないけど、PGであるならPGとしての価値がなきゃだめ...だねってのはあるよね

    --
    M-FalconSky (暑いか寒い)
typodupeerror

未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー

読み込み中...