マーチン・ファウラーのリファクタリングを読んで（第１〜４章）
マーチン・ファウラーのリファクタリング、
とりあえず第１章から第４章のリファクタリングの始め方的なのを読んだので、
一旦まとめてみる。
まだ実際のリファクタリングの方法より、なぜするのかとか、どう始めるのかの辺りですが。
なぜリファクタリングをするのか
リファクタリングすると何がいいの？動いてるからいいじゃん。
ってよく言われますが、
- コードを理解しやすくなる
- → バグを見つけやすくなる
- → より早くプログラミングできる様になる。
- → スケジュールがスムーズに進む
というところで、結局みんながHappyになれる！
「スケジュールを気にする管理者は、
スピーディな方法を望むが、どうやってやるかは知らない。」
結局はこれなので、もし管理者を説得するなら、
この流れで説得するのがいいのかも。
- リファクタリングは設計を保管する
確かに。
最近コードを書くときは、設計はざっくりで、
まず書いてリファクタリングして設計に戻るほうが穴がない。
結局、ウォーターフォール的に先にがっちり設計するよりも、
書いたコードは想定以上のことを見つけられる。
「最初の設計は穴だらけなはず」
まさにこの通り。
-
変更しにくいコードから離れられる
「読みにくい」
「ロジックが重複」
「既存の修正が多い」
「条件分岐が複雑」
こういうコードは変更しづらい、
だから、リファクタリングによって変更を容易にする。
それによって開発効率は上がる。バグは減る。
リファクタリングって、
エンジニアのこだわりとかじゃないんです！
いつリファクタリングをするべきか
- 機能追加の時
- バグフィックスの時
- コードレビューの時
この中で書いてあったのが、
「リファクタリングをリファクタリングだけの時間で切り出さない」
というところかな。結局行う時間が確保できずに借金になりがちだし。
リファクタリングをしてはいけない場合
- 変更するより書きなおしたほうが早い
- 期間が迫っている場合
ちょっとこれは本に書いてあるけど、あまり納得できないかな。
このパターンでリファクタリングできないことが多いんじゃないかと。
まぁ、僕は書き直しますが苦笑。
ただ、
「未着手のリファクタリングは借金」
とはいえ、今はしないけど借金ですよというのも書いてあった。
これ、測れるとリファクタリングをちゃんとできる様になりそうだな。
どうやって測るかな。。。
リファクタリングをする時に最初にすること
テストを書く！
ってまぁあたりまえというか、これをしないと安心してリファクタリングできないですね。
PHPだとFixtureとかPHPUnitで、JavaだとJUnitとかですね。
そのテストを書く時に注意するべき点は２つ
- 実行されない完全なテストより、実行される不完全なテストの方が良い
- 例外のテストを忘れない
無駄にpublicなメソッドのテスト全部書いても、リファクタリングには無意味ですね。
でも、最近思うのは、先にテスト書いておかないと、テストしにくいメソッド構成とかになってて、結局テスト前にリファクタリングが発生したり。。。
テスト大事！
リファクタリングを始める（まずやってみること）
でも、ここで何行以上とか決めちゃうと無駄にメソッドが分割されて結局読みにくくなりそうなので、そういうのはやめておいた方がいいんじゃないかなと。
確かに無駄に一時変数が多いと読みにくいしバグになりやすい。
変数を無駄に増やさない！
ローカル変数を問い合わせによる取得にすれば、その部分だけテストできるし。
- メソッドの移動
使用するデータを持つオブジェクトにメソッドは定義されるべき。
ポリモーフィズムを取り入れるのもいいかと。
「そのメソッドが呼び出されたとき、どう振る舞えば良いかはそのオブジェクトが知っている」
例：Switchは自分自身に対して行うべき
この時、わかりやすい様に、メソッド名とか変数名の変更を躊躇しないのも大事。
ここはまだ導入部分だけど、これだけでもリファクタリングの概念はつかめるかな。
早く先が読みたい(*´Д`)ﾊｧﾊｧ
ここまでのまとめ
リファクタリングを行う必要性をこの辺りまではかなり説明してくれていて、
もし、「リファクタリングしたいけど管理者を説得できないし・・・」とか
思っている人がいれば、まずここを読んでみるのはいいかと。
さて、やっと実際のリファクタリングの方法論に入っていけるヽ(=´▽`=)ﾉ
