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

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

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

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

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

    ってことだな。

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

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

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

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

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

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

            下手にコードを共通化して複雑にするよりも、
            似たやり方で個別に書いた方が分かりやすくなる場合もあるのです。
            また一部のパターンにおいてより単純化できるとわかっている場合があっても、
            あえて他と設計方針を揃えるために冗長な構造を採る場合もあります。
            ボトルネックとなる箇所ならともかく、パフォーマンスに大差が無ければ、
            より書きやすくメンテナンスのしやすいコードの方がむしろ高品質といえる場合も少なく無いのです。
            • by Anonymous Coward
              #1254963 [srad.jp]のACです。
              コピペ=低製造コスト
              ってことで考えてました。

              出来上がったものの品質を計るには、どうしたら良いですかねぇ?
              品質を考えると、納品後のバグ率とかですかね?
              品質の視点からすると、バグが少ない、変更が容易(短時間で済む)のが、良いコードかなと思うのです。

              そうすると、コピペ三昧でも、関数大増殖でも、あまり構わない。
              要は、バグが少なくて、変更しやすい(程度によるでしょうけど)のであれば、
              コーディングがどんな華麗か!どんなに醜悪か?なんてどっちでも良いん
              • by Anonymous Coward on 2007年11月26日 2時02分 (#1255461)
                >でも、お支払いする対価は、決まった額だけ。

                というか、いざバグが出たときの修正費用を
                どっちが持つか
                (製造元か、それとも追加料金を頂くか)
                っていう論点で
                営業のかたがたは日夜奮闘なさってるようです。

                よく判らないんだけど、
                「それが」営業の仕事なんだろうか?とは日夜不思議に思います。

                あと、「バグが少なくて」といっても、
                バグの定義が問題になるんですよね。
                つまり要求が何を言っていたか?の解釈を洗いなおす羽目になる。
                それ次第でドッチが悪いかがコロコロ変わってしまう。

                ついでにいえば、ちゃぶ台返しというか逆切れするのが大好きなのが日本人ですから、そういう「議論」は得てしてグダグダの泥沼になります。

                そういうリスクを思うと、最初から「決まった額だけ」という風に決めてしまう契約を(安全に)こなすために、要求を受け取った後に作り手がヤらないとならないことは、要求の洗い直しです。自分らがドツボにはまる落とし穴は無いかどうかのチェック。

                で、恐らくそれに無限に近い時間がかかったり、質問してもグダグダで答えが帰ってこなかったり、するのではないかと。
                親コメント

吾輩はリファレンスである。名前はまだ無い -- perlの中の人

処理中...