リファクタリングについて調べてます。
この記事の続き。
リファクタリングについて調べはじめた - blog.mtb-production.info
キチンとしたリファクタリングのやり方を知りたいと思ってます。*1
というわけで、この本を読んでます。
新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)
- 作者: Martin Fowler,児玉公信,友野晶夫,平澤章,梅澤真史
- 出版社/メーカー: オーム社
- 発売日: 2014/07/26
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (11件) を見る
本を読んでいて、自分なりにポイントだと思ったことを書いています。最後に所感も書いてます。
リファクタリングの頻度
リファクタリングは定期的にやることではなく、何かをやる時に一緒にやること。
- Bad：定期的（例えば、二週間に一回）やる。
- Good：リファクタリングするべきタイミングでやる。
リファクタリングをやること
リファクタリングは目的ではなく、手段である。
リファクタリングのタイミング
次のようなタイミングでやる。
- 三度同じことをしていることに気づいたらリファクタリングする。
- 機能追加時に、既存機能を理解するために、リファクタリングを利用する。
- 機能追加時に、機能追加を容易にするためにリファクタリングを行う。
- バグフィックスの際に、コード見通しをよくするためにリファクタリングを行う。
- コードレビューの際に、コードを理解するためにリファクタリングする。
リファクタリングしないとき
次のタイミングでは、リファクタリングを避けます。
- コードが汚すぎて書き直す方が早いとき
- 既存コードが動かないとき
- 締め切りが迫っているとき
なにをリファクタリングするか
所感
この話の中だと、一番良かったのが、何かを対応する中で理解のためにリファクタリングするということ。
ちょうど、開発してるコードでも、新しい機能を作ったら、元のコードで気になる部分が出てきていた。
新しく作っている機能がなかったら気にならなかったけど、新しい機能を追加したら気になることがある。
たとえば、新しい機能があることで既存機能の変数名が誤解を招くとか、無駄な処理があるとか、そもそも、設計が微妙になるとか、そういうやつ。
そういう微妙ななにかは、新しい機能を追加するときにわかるし、それはリファクタリングすべきコードだということがわかった。
そして、リファクタリングした際に、デグレートしてないかを確かめるためにユニットテストが有効に作用する。
ユニットテストがしっかりしていれば、リファクタリングがスムーズにできることがわかってきた。
あと、これまではユニットテストを書くのが遅かったけど、ユニットテストを書くスピードが上がれば、ソフトウェア品質と開発スピードを保ったまま、ソフトウェアを拡張していけることがわかってきた。
これまで、設計した後にコーディングをする。そして、コーディングの段階で、設計を修正しないといけないのがわかったら負け。みたいなマインドがあった。
コーディングする前に、設計が全部わかるわけないでしょ。と思っていたけど、『僕が実力不足なだけで、できる人ならコーディングする前に設計が終わるのかもしれない。』とも思ってた。
ただ、この本を読みつつ仕事をしてる中で真実はこうでは？と思ってることがある。
- 設計してからコーディングした方が良い。（必須ではない。規模、複雑さ、何回使いまわすか、による。）
- コーディングする前に設計が完了するときもある（だいたい作ったことがあるシステムと、全く同じものを作る場合は近いかもしれない。ただ、ホントにそんなことある？チュートリアルか？）
- 設計してからコーディングして、その後に設計を修正することはある。（必ずではない。コードの目的が何なのかによる。）
- 前は良かった設計が、新しい機能追加によって悪い設計になるときがある（拡張性が高ければ良い設計ではない。拡張されないのに、拡張ポイントを作ると、逆に読みにくいコードになる。コードが読みにくいければ良い設計とは言えない。）
- 時間と共に設計は、腐っていくので改善しないといけない。（周辺環境によって、設計が良いか悪いかは変化するし、周辺環境は時間と共に変化していくので、それに合わせたリファクタリングが必須。）
とりあえずおわり。
*1:キチンとした、ってなんか型にハマってて、書いてあることしかやらなさそうな響きが個人的には好きじゃないんだけど、そういうのはとりあえず基本をしっかりしてから言う事な気がしてるのでとりあえず基本的なことをやりたい気持ち。
