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

おすすめのソースは?」記事へのコメント

  • by Anonymous Coward on 2006年09月03日 18時46分 (#1011005)
    目的を一番早く達成できるコードが 一番いいコード デザインパターンとか こんなことしちゃいけないみたいな本からは 最近距離を置いて 無視する場合もある。 みなさんデザインパターンとか こんなことしちゃいけないみたいな本にとらわれすぎ な様な気がします。 必要なときに 必要箇所を直す(もちろんリファクターも含めて)それが一番いいです。 とらわれすぎると、何も書けないような気がする あくまでも 迷ったときの指標に と思ってます。 だから ソースも おすすめのソースはないと思う。 そのときはそれが一番合理的だったから 書いたのですから。
    • Re:目的に合わせて (スコア:2, すばらしい洞察)

      by cassandro (6035) on 2006年09月03日 19時14分 (#1011013)
      > 目的を一番早く達成できるコードが一番いいコード 

       目的は何、というのがありますね、まず。

       単にコードを書けば良いが目的なら、それ以下の記述は首肯出来るでしょう。やっつけ仕事で手早くお金を稼いで、後は野となれ山となれ、の場合も同様。

       将来に渡って維持しなければならないコードであるとすれば、たとえ相当に出来る人であってもこういう事を言い出す人は排除して行く方が後々のためになる場合が多くあります。

       お客がお金を呉れれば問題無いですけど、瑕疵対応とかサービスとかでお金が貰えないとすれば、運悪くやっつけのコードだった場合は、持ち出しとして百万円単位、千万円単位でお金が飛んで行きますからね。
      親コメント
    • デバッグ工程とかメンテナンスとか改版とかの後工程を考えると、設計段階で殆ど何も考えないで勢いで書いたコードって非常に後工程の邪魔になるんですよね。

      設計段階で要求される動作やグローバルな構成を考えるのに若干の労力と頭脳を振り分けるだけで、後工程の苦労が全く違いますので…特にバグが出たときや仕様変更が顧客から出たときに「ここだ!」と言う変更を要する場所の特定や確認を行う事を考えると構造設計を練ることとモジュール化による機能分類を徹底する事は重要だと思いますよ。

      親コメント
      • 将来の仕様変更とか考えるのもいいけど、そのために複雑な仕組みを抱え込むくらいなら、シンプル・単純で通した方がいいこともあると思う。仕様変更などで単純さが保てなくなくなったら、単純になるように変更かけつつ。
        もちろん、何も考えないで書くわけじゃなくて「一番単純な方法はどれか」を練って書くわけだけど。
        • > 将来の仕様変更とか考えるのもいいけど、そのために複雑な仕組みを抱え込むくらいなら、
          > シンプル・単純で通した方がいいこともあると思う。

           #1011005や#1011144のAC氏と、Artane氏やボクの見解の相違は、目的とか到達点の違いでしょうね。プログラムを組む事と、プログラムを組んで維持して行く事の様な。

           以前ボクが書いた [srad.jp]「大体、GNUのコードとかでプログラミング作法を覚えた人は」云々も、自分の為だけにコードを書く人には当てはまらないです。実際ボクにしてから、維持するつもりも人に見せるつもりも無い使い捨てのコードは、相当いい加減に書いてますしね。

           だけど、状況が違えば対応が変わるのは当たり前の話なんです。最近、ある会社が開発したリアルタイムOSの致命的なバグを自前では取れず、社外にバグ取りを出したと言う話を聞きました。問題は奥深い所にあったものの、開発会社がまともな管理手順を踏んでいたら、避けられたはずの問題だったんです。まともな管理手順を踏んでいたら、別会社へ出すまでも無く、早々に片づいていたはずの問題だったんですね。結局、場当たりの開発のツケは数年の時間と数千万円の出費、そしてリアルタイムOSの製品としての未来、となってしまった訳です。

           趣味と仕事なら対応が変わるはずなんです。それが仕事とすれば、やるべき事をやらない事が、どれだけの出費になるのかを考えるべきなんですね。プログラムは組めるけれど、それを維持して行く事を考えない人、と言うか積極的に反対する人、こういう人を雇う/に仕事をお願いするコストは単に報酬だけじゃありません。将来的な大損害の可能性も考えるべきなんです。
          親コメント
          • シンプル・単純が、将来的な大損害の可能性を回避できる一番の方法だったりするわけだけど...?

            複雑なコードを書くやつに限って、自分のデバック能力の限界をしらない人が多くないですか?
            • > シンプル・単純が、将来的な大損害の可能性を回避できる一番の方法だったりするわけだけど...?
              > 複雑なコードを書くやつに限って、自分のデバック能力の限界をしらない人が多くないですか?

               Artane氏の「デバッグ工程とかメンテナンスとか改版とかの後工程を考えると、設計段階で殆ど何も考えないで勢いで書いたコードって非常に後工程の邪魔になるんですよね」からすれば、コードのシンプルさが論点では無くて、コードを書く手順のシンプルさが論点となるのが分かりません?

               さてさて。コードが不必要に複雑なのが良くない、なんてのは、まあ常識。言うまでも無い事です。しかし、コードを単純にしておけば問題が起こらない、なんて方法論は、それこそ10分でコーディングが完了する規模で通用する話。人月と言う単位は使いたくないけれど、0.000947人月程度ですね。

               デバッグとかテストが、個人の力量によって成否が決まるなんてのも、まあ同様ですね。メンバからダメダメ君を排除したいと言うのは誰もが考える事ですけど、場当たり的なデバッグとかテストとかが全てと言うのは、極めて小規模な場合に適用出来る話。

               そんな規模が小さすぎて参考にならない方法論を100とか1000人月の規模で適用したとすれば、まあ、会社の1つや2つ、簡単に潰れるんじゃないですか。言う方も言う方だけど、やらせる方もやらせる方。意思疎通に難がある人に仕事を任せるのもそうだけど、潰れても仕方が無い事をやっているなら、それは潰れるでしょうね。大損害は確定、と言う所でしょう。
              親コメント
              • 設計段階からシンプル・単純の方がいいってことですが、話が通じていないようですね。

                後工程のことを考えすぎて使い物にならない設計ばかり見てきたからかも知れませんが、小規模の場合にしか当てはまらないって決めつけるのはどうかと思います。
              • シンプル・単純な正解例を集めて出来たのが
                デザインパターンとかになると思いますが。

                個人の経験だけで解決できる自信があるなら、
                そんなものを参照する必要は無いと思いますけどね。
              • > 設計段階からシンプル・単純の方がいいってことですが、話が通じていないようですね。

                 簡単に済むことを複雑にする必要は全く無いですね。だが、本来追わなければならないのは最適解であって単純ではないのです。この2つは違うものであるのは理解していますか?

              • > 後工程のことを考えすぎて使い物にならない設計ばかり見て
                > きたからかも知れませんが、小規模の場合にしか当てはまら
                > ないって決めつけるのはどうかと思います。

                 簡単に出来る事を複雑にする必要は無い、当たり前の話です。何故当たり前の話に拘泥するのか、理解出来ませんね。

                 「シンプル、単純」が思考や開発態度のシンプルさ、単純さを意味していないなら結構な話。だけど世の中そうは行かないのが通例で。「シンプル、単純」が思慮不足、手抜きとなる場合が多い事は目を覆うばかりですね。#1011005や#1011144、#1011199に、過去に直面した思慮不足や手抜きと同じ臭いを嗅いてしまったのですが、それは勘違いなのでしょうか。
                親コメント
      • 「デバッグには実装の倍の能力が必要である。従って、全力を尽くして書いたコードは定義よりデバッグ不能である。」というやつですね。

目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond

処理中...