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

同僚の書く酷いコード、どうやって気づかせる?」記事へのコメント

  • by Anonymous Coward

    可読性が悪くても、スパゲッティになっていても、動いてナンボだと思います。

    そもそも良いコードと悪いコードに違いって何でしょうか。

    • by Anonymous Coward on 2013年01月05日 14時15分 (#2300709)

      すでに述べられていることなので、マトメ的な話になろうかと思いますが、

      一度だけ動けばいいのであれば、好悪は全く問題になりません。
      たとえば perlなどで onelinerなプログラムは 記載量が少ないことが
      正義であって可読性などは全く求めません。動けば捨ててしまえばいい
      コードですね。

      二度以上動いて欲しいなら、それは間違った動作をするかもしれないし、
      将来的には若干違う動きをしてほしいかもしれない。
      となれば、未来の自分を含めた第三者が理解できるように
      記載しなくては、それは「悪いコード」となります。

      コードコードといいますが、やってることは 自然言語と同じく、
      命令を連ねることによる主張そのものですから、何をやっているかを
      きちんと人間が分かるように書く必要があります。
      とすれば、「読みやすい」ことが良いコードの条件の1つになります。
      コメントがその補助になるなら記載すべきでしょう。

      あとは保守を考えた場合、同じことを 様々なところに記載してしまうと
      問題が起きた場合に、修正箇所の特定が難しくなるばかりか、
      修正の網羅性が疑われる状況が発生してしまいます。
      エンバグも起こりやすくなります。
      随時 リファクタリングをして、同じコトを別箇所で書く、ということが発生
      しないようにしなくてはいけません。
      ひいては、できるだけ 小さく処理を分けて、メソッドやプロシージャで
      分けておくようにしておくこと、が求められます。
      モジュール化しておけば、DBやら各種入出力などの変更があっても
      ビジネスロジックを守る(そのまま使える)ことができます。
      この「保守性」も 良いコードの条件となります。

      最後に忘れがちですが、「パフォーマンス性」、
      というのも条件のひとつです。
      まず、計算量が高い箇所を特定するにはコードがシンプルで
      あることが必要です。また、高頻度に稼働する箇所が
      不必要な処理で計算量が上がっているなら、そこだけ
      別の単純な処理に換えてやる、というようなことをすれば
      いいわけで、このようなことを考えれば strategyパターンが
      適用できるところはないか、などと考えながらコーディング
      することが重要になるでしょう。

      親コメント
      • by Anonymous Coward

        これ位、丁寧に背景説明をしてくれて、その上で「規約を守れ」なら良いのですが、
        普通は「守れ、以上」なのが現状では無いでしょうか?

        • by Anonymous Coward
          守らせる側もよく理解しておらず、
          さらに守る価値もない規約だったりすることがよくありますね。
        • by Anonymous Coward

          残念ながら、こういったことを説明したとしても理解いただけない方が多い、というのが現状ですね。

          初めてプロジェクトに参加される方には80:20の法則はもちろん、計算量を減らすため
          に何をすればいいか、基本的なアルゴリズムの性質から、CPUの構造まで落としこんで
          説明するようにしていますが、なかなか いいコードはでてきません。
          大規模になれば、コードレビューする余裕もないのが普通でしょう。

          幸い、静的なコード解析ツールや、beautifier、コーディング規約の準拠度を調べるような
          ツールがありますので、一定以上のレベルには落とし込めるのですが、
          それでもコメントの整備などは、どうしてもうまくいきませんね。
          ペアプロや BDDを実践すれば、否応なくコメントが集まるのでしょうが、小規模以上の
          プロジェクトで試みるのは躊躇してしまいます。

          • by Anonymous Coward

            自分は一人でプログラムを作っていても、後段のテストなどに役に立つ資料が作れるのでは
            無いかと考え、ボイスレコーダ(3千円程度。安くなったものです。)を買い、プログラム中に
            口述を試したのですが、いつもコメントに書いている事以上の事は思いつきもしませんでした。

            もしかすると、コメントを書けない人は、もっと反射的なは虫類の脳を使ってプログラミングを
            しているのでは無いでしょうか?
            だとしたら、ペアプロやBDDをさせると非常に高負荷がかかり、拷問にも似た状態になって
            しまう可能性すら有ります。

        • by Anonymous Coward

          それくらい専門学校で教えられてると期待するのは無理なんでしょうか。
          (専門学校出てない方は、自分で学習してね)
          個々の規約が好ましいかどうかの議論は別。

          • by Anonymous Coward

            仮に教えているとして
            「教わっている」と「覚えている」「身についている」は別の話ですし……
            (無駄に教育内容に敵意を持ってバカにする人とかも湧くし)

      • by Anonymous Coward

        セキュリティー的にはどうなのでしょうか?

        6;

        と書いてあるより、

        //因数の1つは2
        6;

        と書いてある方が、分かり易いですが、セキュリティー的には
        がたがただと思います。

        • by Anonymous Coward

          コメントそのものがセキュリティ上の問題になる、という指摘でしょうか。
          これはプロジェクトの性質にもよると思いますが、3つの返答ができるでしょう。
          ・コーディング規約上は、「リテラルをコード上に記載するなかれ」
              というのを入れておきましょう。"6"なるものが地の文に出てくること
              自体をなくします。
          ・コードを納入したりライブラリとして共有することがあるのならば、
              逆にこういったコメント記載はより必要性が高いでしょう。
          ・Webなどでソースをさらさないといけ

人生unstable -- あるハッカー

処理中...