ソフトウェアの開発が進む中で、あらたにドメイン(問題領域)の知識が発見され、ソースコードに追加する。ひとつひとつはちょっとした変更。 その結果...
・メソッドが長くなる
・条件記述( if 文 ) が複雑になる
・クラスが巨大になる(変数やメソッドの増加)
・メソッドの引数が増える
マーチンファウラーの リファクタリング や、ジョシュア・ケリーエブスキーの パターン指向リファクタリング入門 で、コードの「いやな臭い」とされている現象ですね。
この現象は、さまざまなドメインの知識をソフトウェアに盛り込んだ結果として、評価はできる。単純なソフトウェアから、問題領域の知識を増やし、もっと役に立つソフトウェアに洗練しようとした結果だから。
ソースコードとしては、分かりにくく、扱いにくくなり、大問題。
内容が理解できない、ひとつの変更の副作用があちこちで発生する。それ以上の改良(変更)は、だんだん現実的ではなくなる。
メソッドが長くなりはじめ、条件記述が複雑になりはじめ、クラスが大きくなりはじめ、メソッドの引数が増え始めたら、迷わずリファクタリングをしましょう。
開発を何日もストップするわけではありません。
日々の開発の作業で、ソースコードのインデントの調整や、空白行を入れて読みやすくするのと同じ感覚で、ちょこちょこやる。それがリファクタリングの基本だと思います。
しかも、最近はIDEが、リファクタリングをサポートしてくれるので、リファクタリングはずいぶん簡単に安全にできるようになった。
・メソッドが長くなる
・条件記述( if 文 ) が複雑になる
・クラスが巨大になる(変数やメソッドの増加)
・メソッドの引数が増える
マーチンファウラーの リファクタリング や、ジョシュア・ケリーエブスキーの パターン指向リファクタリング入門 で、コードの「いやな臭い」とされている現象ですね。
この現象は、さまざまなドメインの知識をソフトウェアに盛り込んだ結果として、評価はできる。単純なソフトウェアから、問題領域の知識を増やし、もっと役に立つソフトウェアに洗練しようとした結果だから。
ソースコードとしては、分かりにくく、扱いにくくなり、大問題。
内容が理解できない、ひとつの変更の副作用があちこちで発生する。それ以上の改良(変更)は、だんだん現実的ではなくなる。
メソッドが長くなりはじめ、条件記述が複雑になりはじめ、クラスが大きくなりはじめ、メソッドの引数が増え始めたら、迷わずリファクタリングをしましょう。
開発を何日もストップするわけではありません。
日々の開発の作業で、ソースコードのインデントの調整や、空白行を入れて読みやすくするのと同じ感覚で、ちょこちょこやる。それがリファクタリングの基本だと思います。
しかも、最近はIDEが、リファクタリングをサポートしてくれるので、リファクタリングはずいぶん簡単に安全にできるようになった。