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

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

  • by Anonymous Coward
    目的を一番早く達成できるコードが 一番いいコード デザインパターンとか こんなことしちゃいけないみたいな本からは 最近距離を置いて 無視する場合もある。 みなさんデザインパターンとか こんなことしちゃいけないみたいな本にとらわれすぎ な様な気がします。 必要なときに 必要箇所を直す(もちろんリファクターも含めて)それが一番いいです。 とらわれすぎると、何も書けないような気がする あくまでも 迷ったときの指標に と思ってます。 だから ソースも おすすめのソースはないと思う。 そのときはそれが一番合理的だったから 書いたのですから。
    • デバッグ工程とかメンテナンスとか改版とかの後工程を考えると、設計段階で殆ど何も考えないで勢いで書いたコードって非常に後工程の邪魔になるんですよね。

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

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

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

           以前ボクが書いた [srad.jp]「大体、GNUのコードとかでプログラミング作法を覚えた人は」云々も、自分の為だけにコードを書く人には当てはまらないです。実際ボクにしてから、維持するつもりも人に見せるつもりも無い使い捨てのコードは、相当いい加減
          • シンプル・単純が、将来的な大損害の可能性を回避できる一番の方法だったりするわけだけど...?

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

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

               さてさて。コードが不必要に複雑なのが良くない、なんてのは、まあ常識。言うまで
              • by Anonymous Coward on 2006年09月04日 13時00分 (#1011311)
                設計段階からシンプル・単純の方がいいってことですが、話が通じていないようですね。

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

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

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

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

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

                 「シンプル、単純」が思考や開発態度のシンプルさ、単純さを意味していないなら結構な話。だけど世の中そうは行かないのが通例で。「シンプル、単純」が思慮不足、手抜きとなる場合が多い事は目を覆うばかりですね。#1011005や#1011144、#1011199に、過去に直面した思慮不足や手抜きと同じ臭いを嗅いてしまったのですが、それは勘違いなのでしょうか。
                親コメント

ソースを見ろ -- ある4桁UID

処理中...