パスワードを忘れた? アカウント作成
6613 story
プログラミング

リファクタリングは趣味の世界? 338

ストーリー by Oliver
明日は必ず来る 部門より

Anonymous Coward曰く、"リファクタリング(マーチン ファウラー著 「リファクタリング」)とは「ソフトウェアの外部的振る舞いを保ったまま内部の構造を改善していく作業」のことで ここ最近、本屋さんでよく見かけるようになった開発手法XP(eXtreme Programming)の重要な要素の一つです。しかしながら、「動いているコードはむやみにいじくるな」というのは、どの会社でも暗黙のルールになっており、会社の人にも言われることだと思われます。
当方は新人プログラマなのですが手が空いた時にリファクタリングをしていると「きれいなコードだとかそういうのはどうでもいいから一度テストしたコードに手を付けるなボケ。自己満足は一人でおねがい。」と言われる始末です。たしかにリファクタリングは闇雲に行うと何日もの手戻りにもなりえます。しかし、体系化したリファクタリングを行うことにより「将来の機能拡張のために、コードを分かりやすくシンプルな状態に保つ」ことができ仕様変更が頻繁に発生する開発では長期的に見ると工数節約にもつながると思います。
Slashdotのリファクタリング支持者・反対者の皆さん、皆さんのリファクタリングに対する意見・経験をお聞かせください。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 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だろうがなんだろうが、何持って来ようが救えないんだと思います。

        上記ページによると、どうやら所謂狭義の「設計」だけをきちんとしてればテストができる、というものではないようです。
        色々心がけるべき事柄が有るようです。
        親コメント
  • 開発形態の衝突 (スコア:4, すばらしい洞察)

    by Anonymous Coward on 2003年09月29日 17時23分 (#405464)
    上の方もおっしゃっていますが。

    リファクタリングという手法はコーディングとテストが早いペースで
    回転している時、または開発工程に相当の余裕がある場合のみ有効な
    手法です。

    もし、あなたのいるプロジェクトがウォーターフォール型開発を
    行っているのであれば、「テストが完了している」という状態で
    コードに手をつけてしまうのはまさに自己満足に過ぎません。
    # すでに目的の品質に達したものを、”未テスト”の工程に戻してしまうのですから。

    仕事というのはチームで行うものですので、目の前のコードだけ
    でなく、全体的な進捗やプロジェクト運営ポリシーも気にしてい
    ないと、それはただの「オタのオナニー」であって、「プロの仕事」
    では無いと心得ましょう。

    んでまぁ、余談ですが。

    現代のシステム開発では開発速度と品質が昔より
    はるかに厳しい水準が要求されていますので。
    たかが単体試験工程を手軽に(かつ迅速に)繰り返す事のできない
    時点で私としてはそのシステムの品質はかなり怪しいと思います。
      顧客は検収期間内にすべての試験を再現できるか?
            -> 試験成績書の捏造がおこなわれていない事をどうやって
                  保証する気なのだろう。
            -> 試験工程中に操作ミスがなかった事をどうやって(略

    全てがすべて自動化できるとは思っていませんよ。えぇ。
  • 踊る大捜査線 (スコア:3, すばらしい洞察)

    by Anonymous Coward on 2003年09月29日 17時18分 (#405459)

    正しいことをしたければ偉くなれ! byいかりや長介

    大ヒット御礼につきAC
  • バランス感覚 (スコア:3, すばらしい洞察)

    by Anonymous Coward on 2003年09月29日 18時58分 (#405547)
    なぜリファクタリングしてはいけないか、プロジェクトリーダーに率直に聞いてみるといいでしょう。
    コスト(コーディングやテストなど)と効果(拡張性や技能の向上など)のバランス感覚は大切です。プロジェクトの一部しか見ていない人と、プロジェクト全体を見ている人の視点は異りますから、結論が異なるのが普通です。今のプロジェクトリーダーの考え方がベストかどうか分かりませんが、きっと将来の参考になると思います。

    そういう問題意識をもって取り組むことが、きっと役に立つと思います。
    (そんなの自分には関係ない、という人が多いので...)
  • by Kim H Yusuke (15415) <b_yuutaNO@SPAMhotmail.com> on 2003年09月29日 16時58分 (#405442) 日記
    私のところの会社のメイン商品のリファクタリングプロジェクト
    が数ヶ月続いておりましたが先日ようやく完了しました。
    さっきシャンパン開けて乾杯したところです。

    こういったこと(シャンパンじゃなくてリファクタリングね)
    に対して肯定的なことはいいことだと思います。

    ただし、ここの会社の場合、
    「何!?機能はまったく変わらないのか?(愕然」
    といった声も(営業側)少なからず聞こえます。

    やはりシステム畑以外から見るとそういう考えをするのは
    仕方ないのかなとは思ったり...

    そいえば半年ほど前にガワだけデザイン方面の部課で
    更新した時は社内は大変沸いていたように感じます。
    # 他部とは裏腹にその時のシステム部のシラけムードは
    # ある意味興味深いものがありました。
    • >ただし、ここの会社の場合、
      >「何!?機能はまったく変わらないのか?(愕然」
      >といった声も(営業側)少なからず聞こえます。

      営業さんからは、性能や保守性が上がることに対して、評価する向きが
      少ないかったってことですか?
      親コメント
      • by Kim H Yusuke (15415) <b_yuutaNO@SPAMhotmail.com> on 2003年09月29日 17時36分 (#405477) 日記
        >営業さんからは、性能や保守性が上がることに対して、評価する向きが
        >少ないかったってことですか?

        えぇ、そのへんの説明はしているはずですなんですけどね。
        速度的な不満があるわけでない、とか、今までも保守出来てる
        じゃないかという考えなのでしょう。

        人の入れ替わりが激しく、かつまともな仕様書が無かったために
        あちこちつぎはぎで...改変するにはまず解析から、
        というこれまでの状態からするとかなり効率は上がるのは確実です。

        ただ、プレゼンテーションが上手く出来ていないんじゃないかと
        言われれば反論できないのかも。
        親コメント
        • Re:私のところでも (スコア:2, すばらしい洞察)

          by tokushima (155) on 2003年09月30日 1時19分 (#405770)
          これ以降の不具合への対応や新機能追加が
          これまでと較べて目にみえて向上してこその
          評価じゃないですか?

          リファクタリングが修了しました。
          ただそれだけじゃシステム部だって評価しないでしょ?
          --
          It's not who is right, it's who is left.
          親コメント
  • 開発手法ってのはメンバー全員が統一して行なうからこそ意味があるので、一人だけリファクタリングを実行しても意味ないですね。

    マネージャーになんて進捗報告してるんですか?テスト終わったって報告受けてるところがまた勝手にテスト中に戻ってたら、管理もくそもなくなりますよ。マネージャーの判断にも支障が出る。

    プロジェクトメンバーの同意なしにテストの終わったコードをいじるなんて、もっての外です。

    リファクタリングという手法に問題があるんじゃなくて、タレコミ人の姿勢に問題があるだけですね。
    --
    : 〜〜〜 パルナス、けだるい日曜日。 〜〜〜
  • by gram (10641) on 2003年09月29日 17時32分 (#405473)
    そりゃあ、一度で完璧に満足できるシステム(コード)を書けるほど、スーパープログラマーじゃないですから、
    後になって書き直したいなんてことは、山ほどあります。

    ただ、仕事でやってる限りは、常にその作業をすることによって発生するコストも考えるべきであって、
    リファクタリングをするにあたっては、その目的や効果を明確にした上で、その作業コストの確保の手段や、費用対効果を検討して、
    やるかやらないかの判断をしなくてはいけないと思う。

    新人だったら、上司に相談しましょう。
    どうしてもリファクタリングしたいんなら、説得できるだけの十分な理由、根拠を提示しないと、ダメと言われるのは目に見えてる。
  • 完了報告前なら (スコア:2, 参考になる)

    by Anonymous Coward on 2003年09月29日 20時11分 (#405585)
    自分が書いた部分で完了報告を出す前だったらテスト→変更→テストはありだね。

    ヘタクソなコード書いてると自分がプロジェクトから離れた後も質問がきて
    現在の仕事が圧迫されかねない。
    んで質問来ても昔に書いた自分のコードが読めないと..

    # そんな人が近くにいるのでAC
  • by tito (17124) on 2003年09月30日 7時06分 (#405826) 日記

    これは誰の問題なのか。

    1. 新人プログラマ
    2. プロジェクトリーダー
    3. プロジェクトの他のメンバー
    4. 新人プログラマが勤める会社の上司
    5. 新人プログラマが勤める会社の社長
    6. システムを発注した会社の担当者
    7. システムを使うエンドユーザー
    #あとが続かないけどID
  • 新人さん (スコア:1, 興味深い)

    by Anonymous Coward on 2003年09月29日 16時59分 (#405444)
    >当方は新人プログラマなのですが

    新人にリファクタリングさせるのは怖いね。
  • by Anonymous Coward on 2003年09月29日 17時14分 (#405452)
    タレコミ文より
    > 手が空いた時にリファクタリングをしていると

    勝手に中身をいじっちゃったら、そりゃまずいでしょ。
    きちんとリファクタリング・プロジェクトを立てて実行してるなら、問題はないと思いますが。

    # うちの会社は、たぶんリファクタリングには予算つけてくれないだろうな。
    # というか、時間的にも開発メンバーは余裕なさそうな……
  • by Anonymous Coward on 2003年09月29日 17時23分 (#405465)
    時と場合によります
    私はそんなに経験豊かではないですが
    会社の方の言い分も一理あります

    私の場合、リファクタリングする場合は

    1 リファクタリングの意味を顧客が理解しており、
        且、その作業分の金がでる

    2 リファクタリングしてもシステム全体に
        影響がないことに確信がもてる
        (コードを最適化してバグがでたら、まずいです)

    3 リファクタリングした結果何か発生しても
        すべて自分で解決する覚悟・自身がある

    ほかにもいろいろありますが、最低でこの3つ
    をクリアしないと、よいと思っても手を出しません。
    (他にやることはいくらでもありますし・・・)
    プロと趣味のプログラマーについては、各人でいろいろ
    あると思いますが、
    みなさんはどうお考えですか?
    • by Led (7726) on 2003年09月29日 17時42分 (#405489) ホームページ 日記
      >1 リファクタリングの意味を顧客が理解しており、
      > 且、その作業分の金がでる

      マーチンファウラーの本だとたしか、
      「リファクタリングすることで将来の保守・拡張を容易にし、
      結果的にプロジェクト全体のコストを下げることができる。」
      と主張していたと思いますが、
      親コメントのような発言が出ると言うことは、
      まだまだ効果を実際に見ることができた人は少ないんですね。
      --
      Something really matters.
      親コメント
      • by Anonymous Coward on 2003年09月29日 18時09分 (#405514)
        顧客の考え方しだい
        ですね、
        だいたい「リファクタリングしたほうが・・・」
        と提案した場合の反応はこんな感じか?

        良い顧客
        「将来的にそのほうがうち(顧客側)で開発やる場合も
            都合がいいから、別見積もりでいいから、やってよ」

        普通
        「いまテスト終わって、ちゃんと動いているんでしょ?
            こっちも上司と期日を約束してるから
            余計なことはしなくていいよ、」

        少し悪
        「良くなるんだったらやってよ!もちろん納期も
            いまのままで費用も当初の見積もりには
         いっているんでしょ?」

        極悪∞
        「ええ、よくなるんならお願いします(眩しいほどの笑い)」

        後日、リファクタリングした箇所にちょっとした
        ミスが出ると・・・
        「ふざけんなよコラ!だったら値引きしろや!!(できればタダ)
            もちろんサービスで保守半年無料もつけるよな!!」

        まあ、極悪∞もたまに見かけるな
        親コメント
        • Re:学生ですが (スコア:1, すばらしい洞察)

          by Anonymous Coward on 2003年09月29日 18時18分 (#405524)
          「良い顧客」「悪い顧客」というのは正しくないですね。
          「(あなたにとって)都合の良い顧客」「(あなたにとって)都合の悪い顧客」が正しい。

          # リファクタリング=善とは限らない

          親コメント
      • by raf (9322) on 2003年09月29日 18時14分 (#405519) 日記
        機能拡張をしてもらえるシステムっていうのがまれなだけ何じゃなかろうかと。
        会社側としては作って稼働したらちょこちょこと調整してそれまでっていうシステムに
        リファクタリングなんていう再生産の手間をかけたいとは思わないんじゃないかな?
        --
        -- 星を目指さない理由は何もない -- 「MISSING GATE」by 米村孝一郎
        親コメント
  • by Anonymous Coward on 2003年09月29日 17時26分 (#405467)
    ちゃんと動いているコードをリファクタリングするな」 というのは、
    既にこの問題を解くアルゴリズムが出来てるんだから、新しいのは作るな
    と言われていると思えて仕方ありません。 ほんの少しデータ構造などを変更するだけで実行速度が劇的に速くなったりすることもあるので (ライブラリを使ってたとしても、それが今実行したいものに対して不向きだったりする場合もある) 完成品でも多少見直すくらいはしても良いと思います。

    #現場を知らないど素人が!と言われそうなのでAC
    • by libra55 (2515) on 2003年09月29日 17時37分 (#405478) ホームページ
      コスト意識とプロジェクトが共同作業であることを覚えましょう。

      自己満足でお金はもらえないんです。お客さんもよろこびません。
      --
      : 〜〜〜 パルナス、けだるい日曜日。 〜〜〜
      親コメント
    • by Anonymous Coward on 2003年09月29日 17時55分 (#405501)
      「動いているものをいじるな」というのは、動いているものをいじる事自体より、それに伴って発生するコストが莫大であるために言われているのです。
      現場を知らないど素人は「リファクタリングに必要なコスト」=「プログラミングにかかる人件費」としか考えていない場合が多いですが、実際には検証にかかるコストやリファクタリングしたものを配布するコスト、配布が完了するまでに複数バージョンが並存する事によるサポートコストの方が何倍も(場合によっては何十倍、何百倍も)かかる事も珍しくありません。
      また、人間が関与するものである以上、変更に伴う諸々のミスにより、動作しなくなるというリスクを0にする事はできません。
      それだけのコストをかけてもなおメリットが得られる場合というのは、そうそうあるものではありません。

      実行速度が劇的に速くなると言っても、今動いているものは、要求された時間内に終了しているのですから、それ以上を求めるのは趣味の世界です。
      (要求された時間内に終了しなくなっているものに対しては「いじるな」とは言わないでしょう)
      「速ければ速い程良い」というのは、まさに現場を知らないど素人の考え方、趣味の世界の考え方ですね。

      親コメント
    • by jtakano (13491) on 2003年09月29日 18時38分 (#405534)
      >「ちゃんと動いているコードをリファクタリングするな」というのは、
      >「既にこの問題を解くアルゴリズムが出来てるんだから、新しいのは作るな」
      >と言われていると思えて仕方ありません。

      アルゴリズムやデータ構造で劇的に改善できるならば
      プロジェクトマネージャとまず相談ですね。
      劇的に改善されるならば、それはまだ完成していない状態ともいえます。
      パフォーマンス(処理時間)も含めたテストで
      OKが出ているのですから一般的には改善の余地は無いと思います。

      そんなアルゴリズムを考えられるほど余裕のあるプロジェクトは
      ここ10年お目にかかっていないですね。
      親コメント
    • by Anonymous Coward on 2003年09月29日 17時41分 (#405486)
      > #現場を知らないど素人が!と言われそうなのでAC

      現場の細かい事情とか知らない人の方が本質を突いたことを言う
      なんてのはよくあるよ。
      親コメント
    • > 「既にこの問題を解くアルゴリズムが出来てるんだから、新しいのは作るな」

      個人的な研究や趣味の範囲はさておき、営利企業における開発なら、そういわれても仕方ないと思います。
      ただし、その新しいアルゴリズムを顧客に説明し、理解してもらった上で、リファクタリングにかかる費用を捻出できるなら、新しいアルゴリズムでリファクタリングすることも認められると思いますよ。企画力・調整力・プレゼンテーション能力が必要です。
      費用の捻出は、顧客から出してもらうことを含みますが、それ以外でも例えば、保守性が上がり社内の保守工数が減ることで相殺できると言ったことも含みます。
      良くも悪くも、営利企業における開発とはそうしたものです。研究だって、チームでやる場合には、勝手にコードをいじることが許されない場合もあるんじゃないかな。私はそういう研究をやったことがないけど。

      個人的な研究や開発であれば、どう行おうと自己責任で、でおしましです。
      親コメント
  • >手が空いた時にリファクタリングをしていると「きれいなコードだとかそういう
    >のはどうでもいいから一度テストしたコードに手を付けるなボケ。自己満
    >足は一人でおねがい。」と言われる始末です。

    それは当たり前。
    特に君が新人君で「自分だけ」手が空いているなら。

    私の場合のリファクタリング実践例としては、

    機能を拡張しろと仰せつかったら訳わからんコードだった。
        ↓
    拡張する前に整理しないと危なくて手が付けられないっす。
        ↓
    リファクタリングするので時間ちょーだい。
        ↓
    さっぱりしたし処理の流れも良くわかった。拡張しまーす。

    て感じかな。大体。
    仕事は何事にも「ホウレンソウ」が基本よ。
  • 言うは易し (スコア:1, 興味深い)

    by Anonymous Coward on 2003年09月29日 17時39分 (#405483)
    私の経験で考えると、
    「将来の機能拡張のために、コードを分かりやすくシンプルな状態に保つ」
    というのはなかなか難しいのでは?と思います。

    将来性を考えれば考えるほど、
    余計なものをあらかじめ用意しなければならず、
    コードはどんどん膨らんでいくような。

    何も考えず、その場しのぎに作ったものの方が
    バグも少なかったりすることも結構あります。

    #私が下手なだけかも。
    • Re:言うは易し (スコア:2, すばらしい洞察)

      by kai_kamome (4560) on 2003年09月29日 17時47分 (#405492) ホームページ 日記
      機能拡張の準備するのではなく。

      後で拡張する時の障害になりそうなもの、
      初期の開発で埋め込まれた余計なコードや概念を片っ端から
      取り除いて行く。
      = 後の建増しの為にあらかじめさら地にしておく。

      というのがリファクタリングだと思っていましたが、まちがって
      ましたかねぇ。。。
      --
      wild wild computing
      親コメント
    • エクストリームプログラミングでは、
      今使わない余計な構造は入れず、現在の要求を満たすために十分な
      機能だけを入れ、全体としてシンプルな状態に保つことによって、
      結局は、将来機能拡張するときにかえって楽になる、
      という考え方に基づいているように思います。

      きっと使うだろうと思って用意した機能が、後になってみると
      全然使われていない、ってことも結構ありませんか?

      実際それを必要とするときになってみると、必要な機能と一致
      していない、ということもあるように思います。

      そういう意味では、「何も考えず」というので正解なのかもしれません^^;
      親コメント
  • by Anonymous Coward on 2003年09月29日 18時03分 (#405509)
    ローカルでテストする分には勉強にもなるだろし、よいんでない?
    片手間でやるならその辺が限度かなぁ。
    いきなり本チャンのコードに反映されると困ると思う。

    # なんて偉そうに言える立場でもないので AC
  • by Anonymous Coward on 2003年09月29日 18時16分 (#405523)
     そんな事してデンジャーな仕様を発見したり、動いていたのが奇跡の様なへっぽこコードだったりしないの?
     しかもそれは潜在バグなので修正代は別費用だろうし、直せばそれで他所がエンバグしたりするだろうし(鬱)

    #世間一般のソースコードって品質高いのね…
typodupeerror

私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike

読み込み中...