パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

「オブジェクト指向言語でオブジェクト指向っぽいプログラミングをしない」のはNG?」記事へのコメント

  • 継承図すら作らずにコーディング始めるとか問題外にも程がある・・・と思ってましたが、
    世の中は案外そんなもんらしく・・・

    #で結局デスマーチ、と
    • Re:問題外 (スコア:4, おもしろおかしい)

      by firewheel (31280) on 2010年05月06日 19時47分 (#1759321)

      継承図なんて要らんよ。フローチャートと同じで、まともなプログラマーにはそんなものは必要ない。

      書いても良いけど品質が上がるわけではないので、結局は時間の無駄。

      親コメント
      • Re:問題外 (スコア:2, すばらしい洞察)

        by duenmynoth (34577) on 2010年05月06日 20時21分 (#1759347) 日記
        概要設計、基本設計、コーディングルール、etcetc・・・
        いろんなものが「自称」優秀なプログラマには必要無いのでしょうね

        #で結局デスマーチ、と
        親コメント
        • Re:問題外 (スコア:3, おもしろおかしい)

          by firewheel (31280) on 2010年05月06日 21時45分 (#1759411)

          >概要設計、基本設計、コーディングルール、etcetc・・・
          見事に全部不要なもんばかりだなあ。感心するわ。

          >いろんなものが「自称」優秀なプログラマには必要無いのでしょうね
          平凡なプログラマでも不要です。

          あなたが平均以下のプログラマーなのは勝手だけど、
          平均以上の人間の足を引っ張るのだけはやめてくださいね。

          親コメント
          • Re:問題外 (スコア:1, おもしろおかしい)

            by Anonymous Coward on 2010年05月07日 1時01分 (#1759546)

            おもおかついてるけど、ネタなのか真性なのか区別がつかん

            親コメント
            • by Anonymous Coward

              真性だから「おもおか」がついてるんだろ

          • by Anonymous Coward

            随分攻撃的だなぁw まあそれはいいけど

            >>概要設計、基本設計、コーディングルール、etcetc・・・
            >見事に全部不要なもんばかりだなあ。感心するわ。

            アジャイルな開発手法もあるし前の二つは必須じゃないが、
            複数人で作業するならコーディング規約は必要でしょ?
            インデントから何からバラバラだとやってられへん。
            まあインデント程度なら整形プログラムで対処できるけど。

            • by Ryo.F (3896) on 2010年05月06日 22時14分 (#1759440) 日記

              複数人で作業するならコーディング規約は必要でしょ?

              コーディング規則が不要な人達を「平均以上」と定義、というオチでは?

              親コメント
              • by Anonymous Coward
                腐ったコーディングルールほどコードの可読性を落とすものも無いと思う。
                「まともなプログラマー」なら常識的なルールは守るから余計なルールは入れない方が安全、的な意味合いで受け取ってあげましょうよ。
              • by Ryo.F (3896) on 2010年05月10日 2時08分 (#1761020) 日記

                腐ったコーディングルールほどコードの可読性を落とすものも無いと思う。

                賛成できません。他にもコードの品質(可読性はその一部分)に影響するものはたくさんあります。例えば、プログラマが「まとも」かどうか、などです。

                「まともなプログラマー」なら

                #1759411 [srad.jp]では、

                平凡なプログラマでも不要です。
                <<略>>
                あなたが平均以下のプログラマーなのは勝手だけど

                と、「まとも」かどうかではなく「平凡」か、あるいは「平均」かが問題になっていますね。
                コーディング規則など不要、と呼べるほどの「まとも」なプログラマーは、「平凡」でも「平均」でもないでしょう。
                そうでないのなら、「腐ったコーディングルール」なんてものは、ほとんど存在しなくなっているでしょう。

                親コメント
            • by Anonymous Coward on 2010年05月06日 23時28分 (#1759490)
              ちょっとまってくれ、コーディングルールはともかく基本設計からインタフェース仕様書までは
              どんな開発であっても複数人数でやるものならば必須だよね?

              アジャイルとかXPとか設計書はいらないなんて開発手法もいわれているけれど
              あれってただの夢物語でJavaがポインタなんていらないぜーとか、メモリリークしないよとかとか
              いっているのと同じレベルだよね?

              設計書もなしでどうやって、機能テストの妥当性をレビューするつもりなんだろう

              内部設計以降はいらないと思うけどさ。外部設計以前は必須でしょ。
              ライブラリつくってはい、おわりーとかだったら別だけど。。。
              親コメント
            • by Anonymous Coward

              > 複数人で作業するならコーディング規約は必要でしょ?
              あまり気にしなくても済んでますね。その場の雰囲気にあわせて常識的な判断で書いてもらうという感じで。
              そもそも、コーディング規約が異なるプロジェクトからモジュールを拝借したりするので。

              • Re:問題外 (スコア:1, 参考になる)

                by Anonymous Coward on 2010年05月07日 8時55分 (#1759634)

                >その場の雰囲気にあわせて常識的な判断で書いてもらうという感じ
                メンバが空気が読める人だけならばそれでうまくいきますね。
                私が以前いたところでは、頑なに自分ルールで書く人がいたのでダメでした。
                例えば既存のメソッドに引数を増やす場合でさえ、
                methodXXX(int code, string name)

                methodXXX(int code, string name, string _strOption)
                みたいな感じにしてしまう。
                これにまた別の人が引数追加すると、
                methodXXX(int code, string name, string _strOption, int Value)
                みたいな。

                合意されたコーディング規約がないと、こういうのを「ダメ」って指摘しづらいんです。

                親コメント
              • by Anonymous Coward

                > メンバが空気が読める人だけならばそれでうまくいきますね。
                たとえば Javaコーディング規約 [sun.com]は空気じゃなくて明文化されてますね。日本は何でもかんでも「空気を読め」「目で盗め」で済ませようとしますが。
                ガラパゴスに閉じこもっていれば「常識」で済ませられるかもしれませんが、「常識」が人によって違うのが常識である世界標準ではむしろくどいくらいに明文化しておくのが当然ですね。
                ただ自然言語で明文化する必要は必ずしもありませんけどね。JavaやCのソースコードをExcel方眼紙で書き直して手

              • by Anonymous Coward

                >日本では既存のコーディング規約を無視して何もかも自分たちで一から作ろうとする

                これが一番の無駄だろうな。

              • by Anonymous Coward

                >そのほか日本では既存のコーディング規約を無視して何もかも自分たちで一から作ろうとするとかどうしようもありませんね。
                俺の住んでる日本と違う日本があるのだろうか?
                っていうかそんな酷い所あるのなら実名あげて欲しいぞ、怖いから

          • by Anonymous Coward

            人数が多いプロジェクトの管理をしてみればわかるが
            平均以下の人もいるし
            俺俺ルールをみんなもっている。
            規約がいらないというのは少人数でやるときだけ。
            ましてやC++なんて規約である程度縛ってあげないと
            自由が利きすぎる。

          • by Anonymous Coward

            >あなたが平均以下のプログラマーなのは勝手だけど、
            >平均以上の人間の足を引っ張るのだけはやめてくださいね。

            あなたの見てるベクトルと世間のベクトルが違うと言うことに気づくことも大事だと思います。

        • by Anonymous Coward
          ひとまず継承図は一人で作る分には必要ないでしょうねぇ
          作っていくうちに間違いに気付けばすぐ修正できるし、
          そこで重要な部分のインターフェイスが変わってしまうようなら設計能力が乏しいってのが分かります。
          いわゆる優秀なプログラマーは一人で全て済ませてしまうので必要ないんでしょう。

          2人以上で開発するときは、それがOSSであっても作った方がいいと思います。
          ただそれに時間かけすぎても無駄なので、ある程度の規模内で一人で作れる所があれば、細かい設計資料は作らなくていいと思いますよ。
      • コードからUML図を作ってくれるツールを使えば、対外的なドキュメントは後から作れるしねw

        親コメント
      • by rti (659) on 2010年05月06日 23時28分 (#1759491) ホームページ

        継承図とかは接合部分にだけあればOKだと思う。
        最下層の部分とかには不要でしょう。
        だって、まともにOOやればクラスなんてどんどん増えていくし。
        全部は書ききれないと思う。

        接合部にだけこんな感じっていう図を用意するのがいいと思う。
        どうしてもほしい人はDoxygenでも使って自動生成すればいい。

        そんで、他人が作ったものはクラスというかモジュールは、ブラックボックスとして利用させてもらいたいっす。
        そのモジュールの中までは興味なし。暇があったら流し読みしたいけど。

        図を一生懸命書く暇があったらテストの一つでも作ってほしいと思うんよ。

        --
        by rti.
        親コメント
      • by Anonymous Coward
        品質は上がらないかもしれないが、納品図書として請求される場合があることを忘れていないか?
        • by firewheel (31280) on 2010年05月06日 21時43分 (#1759407)

          >納品図書として請求される場合があることを忘れていないか?
          そういうことはあるだろうけど、

          >> 継承図すら作らずにコーディング始めるとか
          には当たらんよね。
          その手の書類はコーディング後、又はコーディングと平行して作る物です。

          親コメント
          • Re:問題外 (スコア:1, すばらしい洞察)

            by Anonymous Coward on 2010年05月06日 21時48分 (#1759416)

            というかdoxygen使えばすぐ出来ちゃうよね。

            親コメント
          • by Anonymous Coward

            > その手の書類はコーディング後、又はコーディングと平行して作る物です。
            そうですよね。
            そんな書類よりもソースを見た方がわかりやすいし、確実。
            で、確実にソースに合わせるためには、ソースから起こすべき。

            • by bicycler (35194) on 2010年05月07日 4時41分 (#1759594) 日記
              それじゃあテストケースがコーディングの後からしか作れないんだな。
              無駄な時間をすごしますのう。
              親コメント
            • by Anonymous Coward
              あらかじめ形だけでも作っておかないとスタートラインを切らせてくれないところもあることは知っておいた方がいいと思うぞ。

              # 後で作り直すことは同意
        • by Anonymous Coward
          >納品図書として請求される場合があることを
          それはその場合があれば書けばいいってだけの話
      • by Anonymous Coward
        という言葉を今初めて知った。。。。のです。一般的な用語なのでしょうか。

        クラス図は、多分普通はコードと同期できるんだが(大規模プロジェクトの場合はそうでないのかもしれんがよく知らない)
        シーケンス図書くのは第三者的(1月後の自分も含めて)な理解のために結構有用だと思うのです。

日々是ハック也 -- あるハードコアバイナリアン

処理中...