『リファクタリング第2版』読書メモ

積読していた『リファクタリング第2版』を読みました。

www.ohmsha.co.jp

どんな本？

リファクタリングとは、リファクタリングの意義を前半で解説した上で、後半（6章〜）はリファクタリングのサンプルカタログのようになっています。

私は、1-5章は丁寧に読み、6章以降は、具体的な手順はそこそこに、どんなケースでどんなリファクタリングをするべきなのか、という点を確認していく読み方をしました。

感想

自分が考えていたリファクタリングは、本書で解説されているリファクタリングより少し狭かったなーと感じました。

というのも、自分の考えていたリファクタリングは、

従来よりもコード数が少なくなる（よりスッキリ書く）
適切なクラスに責務を負わせる
実装効率が改善する

などで、「可読性」についてはちょっと意識が少なかったかも、、という感想を持ちました。

以下、「印象に残った箇所」でも紹介していますが、例えば「せっかく一度読んだコードの意味を覚えておくために関数化する」「可読性を採った結果、多少非効率に見える実装になっても、パフォーマンス上は実は無視できるレベルであることも多い」というのは、あまり考えていなかったポイントでした。

本書を読み進めている最中から、早速実務の方でも意識的に取り組んでみましたが、「可読性」を重視したリファクタリングは、結果スッキリ見えるし、メンテナンス性も上がるよなーという印象です。

印象に残った箇所

第1章

理解したコードを埋め込んでおく方法とは、意味のあるコードの塊を関数に

処理をまとめて関数にすることの理由を、再利用とか見やすくするとかぼんやり理解していたが、「せっかく理解したコードの内容を忘れないようにする」ということをしていたんだなと気づきがあった。

ローカル変数を削除することによる大きな利点は、扱うべきローカルスコープが減ることにより、メソッドの抽出がずっと楽になること

この箇所では、ローカル変数を削除する代わりにメソッドを何度も呼ぶことになるコードが紹介されていた。自分だったら、何度も計算するのが嫌でローカル変数にすぐ入れてしまうなーと思ったので、パフォーマンス上問題ない限りは、リファクタリングする上ではローカル変数は減らすべきというのは頭に入れていきたい。筆者は、別の箇所で、パフォーマンス改善もリファクタリングしてからの方がしやすい、とも言っている。一度パフォーマンスのことは気にせず、整理してからパフォーマンスに向き合うというのもアリなんだなーという気づきを得た。

P27あたり

中間データ構造を設けて、計算を担当する部分と表示を担当する部分を切り離すというもの。中間データ構造を設けることで、関連する関数同士を切り離せるようにするという発想は色々な場面で使えそう。

「簡潔さは知恵の要」と言われますが、明確さは進化するソフトウェアの要

コード量が長くなるのは良くないと思いがちだが、それによって明確さが増すのであればむしろ良いコードになるということを意識したい。

第2章

ここのリファクタリングは非常に小さいステップ、またはそれらの組み合わせてでできています。その結果、リファクタリングではコードが壊れた状態になっている期間は非常に短く、たとえ未完成であっても、いつでも中断が可能です。

大規模なリファクタリング計画があったとしても、小さいステップで手順を踏み、その都度テストが通るように行なうリファクタリングを積み重ねるというプロセスを取るべきというもの。実際に私も、リファクタリングするぞ、となった時、ついついいきなり大きく変更を加えてしまうことがあるが、これではリファクタリングになっていないということを意識しないといけないと感じた。

リファクタリングの途中で気がついたバグについては、リファクタリングも残っているべき

リファクタリング中にバグに気づくのはあるあるで、つい直してしまうが、勇気を持って見逃す（メモはしておく）というのも時には必要。今までは、気付いたからには直さないといけないのでは？という気持ちで、リファクタリングを中断してバグ修正を先に行うなどしていたが、この書籍を以て、バグの程度によってはバグを保ったままリファクタリングを続けるという選択肢も持っておきたい。

リファクタリングは、コードベースがどれだけ美しいかではなく、純粋に経済的な基準で測られるもの

あくまでリファクタリングは機能追加等をしやすくするためのもので、3行で書いていたコードをトリッキーなことをして1行にした！（ただし、読みづらくなっている）というような類ではないよ、という話。これは結構勘違いしやすいところがある気がする。

P74, P75

良い名前が思いつかないということは、設計がまだ固まっていないことの兆候でもあります

コメントが必要だと感じたとき、代わりにわかりやすい名前を付けるようにする

今まで何度か聞いた言葉だが、改めて意識したい。

P236「ループの分離」

1つのループで複数のことをやらず、ループを分離しよう、というもの。書籍の例に漏れず無駄に2回ループ回すのを避けてしまうが、パフォーマンス上問題ないケースも確かに多くありそう。

P279「ポリモーフィズムによる条件記述の置き換え」

自分はポリモーフィズムを使うというリファクタリングをする勇気が持てないことが多いので、ここにあるガイドブックをもとに少しずつ挑戦してみようかな、、という気持ちになった。

p 332, p335　「問い合わせによるパラメータの置き換え」「パラメータによる問い合わせの置き換え」

どちらを取るかという１つの基準は「参照透過性」というのはあまり考えたことがなかったので、参考になった。