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

美しくなくても十分に機能するコードで良い?」記事へのコメント

  • ユーザーには関係ないからね。ユーザーにとっては、バグなくちゃんと思った通りに動いてくれるのがいいプログラム
    .NETにして、バグなくちゃんと動いてくれるプログラムが、簡単に作れるのかどうかは知りませんが。
    • 一般論ですが。
      適切な(セキュアな)実行結果を得るためにコードを書くのであって、美しいコードを書く事だけを目的にしてはいけません。

      そりゃあ汚いより美しい方が(一部の、ソースを読む技術者には)嬉しいけどさ、それを利用する大多数のユーザには内部がスパゲティかなんて問題じゃ無いよ。

      #苦労するのはユーザではなく技術者だけで充分だ。(・・・とプロジェクトえっくすで言ってたです。^^;)
      親コメント
    • ユーザーがそのプログラムを必要としているならば、
      コードがスパゲッティであるがゆえに保守が難しい状況はユーザーのためになっていないのでは?
      そもそも複雑になればなるほどバグを誘発するし、リリースも遅れる。
      結果として不利を被るのはユーザーで、関係ないどころじゃない
      • プログラマの立場から言えば、保守しやすい見やすい判りやすいコードを書く方が、バグも減る傾向があるので、そうすべきであるとは思っています。
        けど、「美しいコード」を「並のプログラマでは理解できない、高等なプログラミングテクニックを使いまくったコード」と思ってるのもいるんですよね。そういうコードの保守も大変なんですわ。
        何にしても、ユーザーから見たら、保守が大変か簡単かなんか関係ないです。「とっとと直さんかぁぁぁ!!」で終わりだもの。
        親コメント
      • でも、もう納期切れてお客さんが隣の部屋で待っているのに、
        デバッグ中に「コードが綺麗じゃない」とか言って考え込んでいる人を見たときは、アホかと思いました。

        問題点の洗い出しは終わっていたし、さっさと動くコードを書いて欲しかったです。
        • そのお客さんと今後、どれくらい付き合うつもりかによりけりじゃないでしょうか?

          他の人も言っているように「美しい」の定義にもよりますが、「保守しやすい」がその定義なら、初期の段階でちゃんと設計しておくことは重要です。
          バグが出たときとか、仕様変更が必要になったときとかの労力が違います。

          まあ、そのお客とは金輪際あわん、という場合は、スパゲッティでもいいんでしょうが。
          親コメント
          • >まあ、そのお客とは金輪際あわん、という場合は、スパゲッティでもいいんでしょうが。
            • 後から入った同業他社になめられるといけないので、そういう場合でも綺麗なコードで書くように心がけます。
            • それでも綺麗にでき
            • 気に入らない同業他社がメンテを引き継ぐことが解っている場合は、署名を抜いた上でスパゲッティにして(デリファクタリングと呼びます)おきます。
              そうか、そのせいだったのか...。

              まあ仕様変更への対応と称して換骨奪胎して別コードに仕立て上げたので、もう恨み言を言う気はありませんけど。 :-)

              親コメント
      • 1. コードは汚い、でもいまのところバグ無く動くよ。
        ってのは即興で作るときにはOKでしょ?
        2. コードは美しい、でもバギーだよ。自分で直してね。
        ってのはタブン例外処理を殆どしてないコードを
        無理やり再利用したんじゃなかろーか?
        最初から 美しくてバギーなコード書ける人って
        滅多に居ないと思うけど…

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

処理中...