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

リファクタリングは趣味の世界?」記事へのコメント

  • JUnit, etc. (スコア:4, 参考になる)

    by tty77 (4123) on 2003年09月29日 17時00分 (#405447)
    おそらく、リファクタリングをしたいならば、単体テストを自動化しておくしかありません。そうしておけば、基本的な機能に関して単体テストで担保されますから、大胆な変更も気軽にできるに違いない、と思われます。

    ただし、「動いているものを触るな」文化においては、単体テストを自動化できているということそのものが幻想に近い、という現実があるように思えます。
    とくに、既存のアプリケーションの改修において単体テストを自動化して導入しろ!といわれても、もともと単体テスト向きに実装されていなかったりして、リファクタリングもできずに泣きそうになることうけあいです。

    # 単体テスト環境を整えろ!という状況におちいっているのでID
    • バージョン管理もね (スコア:2, すばらしい洞察)

      by Anonymous Coward on 2003年09月29日 17時16分 (#405455)
      単体テスト(でも自動化って?)が整備されていると同時に バージョン管理で手戻りができることは必須でしょう。 そろっていれば新人にさわらせるのもへっちゃら。
      親コメント
    • by din77 (6693) on 2003年09月29日 18時38分 (#405535)
      おっしゃる通りで、単体テスト、うちの場合は結合テストも自動化してます。それでリファクタリングをするのです。

      単体テストがあれば、いつでもリファクタリングできます。予算ウンヌンの話が出ていますが、要求される納期に間に合わなければいくらテストがあってもリファクタリングはできません。ただし、リファクタリングすることによって要求される仕様の実現がスピードアップする場合はこの限りではありません。

      プロダクトであれば、エンハンスのときに開発メンバが「自分たちのために」頑張って残業でもなんでもしてリファクタリングしてしまえばよいのです。ただし、この場合ひとりよがりなリファクタリングはいけません。あくまで、「コードの共同所有」ができることが前提です。

      親コメント
    • by jud (15801) on 2003年09月29日 17時16分 (#405456) 日記
      > 既存のアプリケーションの改修において単体テストを自動化して導入しろ!

      単体テストの自動化は、新規開発時にやっておいたことがあります。
      1年くらいの間は楽が出来ました。
      まぁ、引継ぎを行って3ヵ月後には引き継いだ方々の無茶な改造で
      まったく無意味になってしまいましたが。

      かといって、途中から自動化ってのは、そのコストを負担するのがいやで
      後々の世代までずるずる引き延ばされてしまうこと往々です。
      まぁあとの世代で実施されたのを見たことはありませんし、
      僕もやったことはありませんが。
      親コメント
    • @IT だったと思うのですが
      「テストはリファクタリングに踏み出す勇気を与えるためのもの」
      でテストコードで保証は取れないという話を見た記憶があります。
      どこまで現実的なのかな~。。

      それともテストコードがきっちり書けるクラス設計を、という事なのでしょうか。ん~。
      親コメント
      • by G7 (3009) on 2003年09月30日 2時25分 (#405784)
        >「テストはリファクタリングに踏み出す勇気を与えるためのもの」
        >でテストコードで保証は取れないという話を見た記憶があります。

        XPでいう「勇気」は、ギャンブルに突入するための勇気…蛮勇…のことを指すのではなく、
        ギャンブルでなくきちんとやれる目処をつけることを指す、のだったと思います。

        #実際できるかどうかはさておき、主張としてはそういうこと、だったと…

        ところで、「テスト可能な」アプリケーションの設計 [ibm.com]なんてなwebページはいかがですか?

        >それともテストコードがきっちり書けるクラス設計を、という事なのでしょうか。ん~。

        「単体」をきちんと定義できているかどうか?っていう問題は、有ると思います。
        どっからどこまでが単体なんだかワケワカなぐちゃぐちゃ設計だと、
        XPだろうがなんだろうが、何持って来ようが救えないんだと思います。

        上記ページによると、どうやら所謂狭義の「設計」だけをきちんとしてればテストができる、というものではないようです。
        色々心がけるべき事柄が有るようです。
        親コメント
    • by pied_piper (7952) on 2003年09月29日 19時20分 (#405560)
      おそらく、リファクタリングをしたいならば、単体テストを自動化しておくしかありません。そうしておけば、基本的な機能に関して単体テストで担保されますから、大胆な変更も気軽にできるに違いない、と思われます。
      よく上のような言葉を単体テストツールの利点として目にするのですが、本当にそうなのでしょうか??
      そもそも、テストコードに全く変更を行わずにリファクタリングが できるほどスマートなクラス設計をしているのであれば、実装を書き直して品質を高める余地は少ないのでは? そしてリファクタリングを行うたびに単体テストコードを書き直すのは結構厄介でやる気が失せる作業です。

      …という意見を他で聞いたことがないのは、自分と自分の周りの スキルが低すぎなのでしょうか…。

      親コメント
      • Re:JUnit, etc. (スコア:3, 参考になる)

        by acute!! (6872) on 2003年09月29日 19時31分 (#405567)
        テストコードはシンプルな仕様そのものです。

        自分も最初は同じ意見でしたが、
        クラス設計以前のお客との意識あわせと要件の
        煮詰めが一番重要で、その要求を満たすこと
        "お客に上げてもらい"それをテストコードで記述するのです。

        クラスの設計の前に、お客自身に自分の言っている
        事の矛盾を自覚させ、自分自身の価値を再認識
        させることが重要なステップです。

        と、最近気付いてようやっと回り始めました。
        親コメント
      • by Anonymous Coward
        > そしてリファクタリングを行うたびに単体テストコードを書き直すのは結構厄介

        原則ブラックボックステストを行うのが試験工程の基本だったっと思います
        ので、いちいちつくりなおすという事は、試験するという事はどういう
        事かが理解でき
        • by pied_piper (7952) on 2003年09月29日 22時50分 (#405678)
          いやいや、作り直すというのはクラス仕様を変えるようなリファクタリングを行う羽目になった場合のことですが。
          JUnitのようなツールを使って単体テストを行う場合の「ブラックボックス」とはメソッドの中身がブラックボックス、になりませんか?

          …と、ここまで書いたところで下の方のコメントを読んでようやく気づきました。
          ワタクシ、JUnitを使った場合だけ、クラス単位のテストを 単体テストと呼ぶものと思い込んでいました…。
          しかも思いっきりその粒度でPJに導入していた。。(((( ;゜Д゜)))ガクガクブルブル((((
          SE何年やってんだ。逝ってきます…。

          親コメント
    • ケント・ベックのTDD本も出たしね。
      http://www.amazon.co.jp/exec/obidos/ASIN/4894717115/249-6954101-0818734
      つーか、この本、目からウロコでした。

アレゲは一日にしてならず -- アレゲ見習い

処理中...