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

新しい材料には新しい検査が必要」記事へのコメント

  • ITでも (スコア:2, 興味深い)

    by Anonymous Coward
    IT畑でこれに似た話といえば、たとえば、

    新しい開発形態には新しいレビュー形態(視点)が必要

    ってことだな。

    例えばOOPコーディングを従来の手続きオンリーの視点で(だけ)レビューすると、的外れなレビュー結果が出かねない。

    (だからOOPをやめる、ってのは適切とは限らないぞ)
    • んー、手法寄りな喩えですな。
      トピ名が「材料」に寄ってるから、ここはプロジェクトで採用するフレームワークやライブラリの話の方が広がるかも?

      行数だけでプログラムの規模や品質測られるよーな笑い話も、減って来てると信じたい昨今ですし
      • by Anonymous Coward
        でもさあ、行数以外の測定方法の決定打がないんだもん。
        何かある?

        # ファンクションで測ろうったって「重み付け」で勘が入るし
        # 機能の複雑さは普通行数に比例するべ?と言われちゃうし
        • by Anonymous Coward
          アイデアとして、コンパイル後のオブジェクト・サイズとか、どうでしょ?
          しかも、zipなりlhaなりで圧縮後のサイズで。
          コピペで同じコードの比率が高いと、その分、圧縮率も上がって、サイズは小さくなる。

          あ、でも、オブジェクトだとコメントがサイズに影響しないから、
          コメント皆無のソースで出来上がってきそうだな…。
          コメントの無いソースはメンテしたくないなぁ…。
          • by Anonymous Coward
            コピペ=品質の低いコードですか?

            多数のよく似た、しかし相互に少しずつ異なる処理を行う場合、
            意図的にコピペを多用する場合があります。

            下手にコードを共通化して複雑にするよりも、
            似たやり方で個別に書いた方が分かりやすくなる場合もあるのです。
            また一部のパターンにおいてより単純化できるとわかっている場合があっても、
            あえて他と設計方針を揃えるために冗長な構造を採る場合もあります。
            ボトルネックとなる箇所ならともかく、パフォーマンスに大差が無ければ、
            より書きやすくメンテナンスのしやすいコードの方がむしろ高品質といえる場合も少なく無いのです。
            • by Anonymous Coward on 2007年11月24日 20時22分 (#1255071)
              あえてコピペを選ぶ気持ち、わたしもわかります。

              ただ、コピペの欠点である、

              コピーしたことを後で忘れてしまう

              もし修正が必要になってもやり損ねてしまう

              のコンボがネックになります。
              これさえなければコピペだってそう捨てたもんじゃないと思うのですが。

              あ。今ふと思ったんですが、
              Subversionのsvn cpコマンドのように
              コピーするのは自由だが、
              そのコピー(どこからどこへコピしたか)は全て後からトレース可能である、
              というコード支援環境をもし用意できれば、
              それで結構幸せになれるんじゃないでしょうか?

              ただし、これをやるのは結構覚悟がいります。
              ファイル単位でのコピー管理では不十分で、
              できるだけ細かい単位のコピーも管理しないとなりません。
              クラス単位は言うに及びません。
              メソッド単位はもちろんだし、
              ブロック単位もやりたいし、
              出来ればそれ以上細かい単位も。
              理想をいえば全てのCopy-Pasteを捕捉したいです。

              そういう意味では介入すべき先は
              ソースコードのエディタでしょうね。
              Eclipseのプラグインでそういうのが出来るならば
              (かつ処理が重すぎたりしなければ)
              (あと他のコード支援系プラグインと衝突しなければ)
              ちょうど良いかも知れません。

              バックエンドはファイルじゃなく
              それこそ例えばSubversionにして、
              全てのCopy-Paste単位を
              内部的にファイルに変換して
              Subversionに登録して管理する、
              などとすれば良いのでは。

              うーん、こう考えると、
              「品質の低いコード」の指標(のうち少なくとも幾つか)は、
              環境次第で変化するものなのかも知れません。

              じっさい、コードそのものではないけど例えば「レビュー」の価値も
              CPU速度のせいで変化してしまいましたよね。
              以前は如何に机上デバッグを徹底するかが重要だったけど、
              今はJUnitでCPUさまに質問したほうが話が早いってことが多い。

              逆にいえば、環境を次世代に移行しないかぎり、コピペはやっぱり難が有るということになるのですが。

              >より書きやすくメンテナンスのしやすいコードの方

              コピペをもう少し正確に分析してみましょう。

              コピペが「書き易い」のは間違いないですね。だからこそみんなやってるわけで。それに比べればそれ以外の理由づけは後知恵の言い訳かも知れないっていうくらい、この「書き易い」という動機は大きいと思われます。

              メンテしやすいかどうかですが、
              これを「読みやすさ」とイコールだと捉えると、
              実のところ処理の共通化という問題に直面「しないかぎり」
              コードはベタガキのほうが(頭からするすると)読みやすい、
              という意見にも一理あると思います。

              ただ、メンテにはもう1つの面があって、
              「そもそも読むべき(そして直すべき)箇所を、見つける」
              ってのもまた楽でないとならないんです。
              よくやるバグ修正の失敗パターンとして「修正もれ」ってのがありますよね。

              で、思うに、ここの点でコピペにマイナス点がついてしまうんだと思います。
              親コメント

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

処理中...