リファクタリングを読んでみたので、感想と心に残った箇所を書き留めておく。
第１章：リファクタリング - 最初の例
最初に小さなプログラムに対して実際のリファクタリングの例がコードとともに挙げられていてすごい分かりやすいし、さくさく読み進められてとても良かった。４００ページ以上あるから、最初に時間かかっちゃうと多分読み終われないだろうから。
リファクタリングを開始するとき、最初にすることは常に同じです。対象となるコードについてきちんとしたテスト郡を作り上げることです。
ユニットテストはクラス・関数の構造変えたりすると、結局ガッツリ手がはいりそうだから、そこまでのリファクタリングをする場合は、ITくらいの粒度のテストを書いたほうがいいのかな。どうだろう。
コンパイラが理解できるコードは誰にでも書ける。優れたプログラマは、人間にとって分かりやすいコードを書く。
あぁ、うまく表現した言葉だな。後者を目指したい。
（バグは結構あるけど）コードが書ける ＜ バグの少ないコードが書ける ＜ バグの少ない分かりやすいコードを書ける
って感じかな。
あと、印象に残ったのは１次変数を極力取り除いていたところ。結果、読みやすいと思う、シンプルで。
第２章：リファクタリングの原則
- リファクタリングはソフトウェアを理解しやすくする
- リファクタリングはバグを見つけ出す
- リファクタリングでより速くプログラミングできる
そのタイミングで直接ユーザに影響があるのは、２つ目くらいだけど、長い目で見てユーザーにもエンジニアにも確実に利益がある。
リファクタリングには２つの価値がある。今できること、そして将来できるようになること。
レガシーシステムの一番の問題は、前者に着目しすぎて何も変えれずに、後者が疎かになって結果的にジリ貧になってしまうこと。
リファクタリングを採用すると、力点の置き方が変わってきます。事前設計は行うのですが、そこで唯一無二の、完璧な解決策を見出す必要はありません。...解決策をコードとして作り込んでいくにつれて、やがて問題の本質がもう少し見えてきます。
結構、設計はふわっとしてまずは動くものを作ってみる。で、そこから構造をいじったり書き方を変えてみたりするリファクタリングを何回かしたほうが、最終的にシンプルで良いものができる気がする。
柔軟性を求めた解決策は複雑になりがちです。その結果できたソフトウェアは、予想していた変更に簡単に対処できるものの、通常は保守しにくくなります。
そうなのよ。将来考えてこんなものを入れています！っていうのは大概複雑で一見わかりにくかったりする。しかも結果使われませんでしたってなるとなんでそんな作りになってるのかもはやわからなくなっちゃうし。
柔軟な解決策を作り込む代わりに、「シンプルな解決策を柔軟なものにリファクタリングするのに、どの程度工数がかかるか」を考えていきます。ほとんどの場合、その答えは、「比較的簡単にできる」になります。そうしたいときは、シンプルな解決策を単に実装すればいいのです。
「将来に向けて柔軟にしました！」は、ちょっとこの基準で考えてみるといいかも。
第３章：コードの不吉な臭い
- 重複したコード
- 長過ぎるメソッド
- 巨大なクラス
- 長すぎるパラメータクラス
- 変更の偏り
- 変更の分散
- スイッチ文
- コメント
最後の「コメント」は、
コメントの必要性を感じたときにはリファクタリングを行って、コメントを書かなくとも内容がわかるようなコードを目指すこと。
によって、解消しましょうねということ。
第６章：メソッドの構成
ここからは具体例を通じて、一つ一つのリファクタリングのパターンに名前をつけてある感じ。
- メソッドの抽出 ⇔ メソッドのインライン化
- 説明変数の導入
- メソッドオブジェクトによるメソッドの置き換え
このあとの章でも出てくるけど、対になっているプラクティスが出てくるのがよい。
要は状況に合わせてより読みやすくなる方を考えて選ぶ必要があるよということ。
第７章：オブジェクト間での特性の移動
- メソッド・フィールドの移動
- クラスの抽出 ⇔ クラスのインライン化
私は、１０年以上もオブジェクトを生業としてきましたが、未だに、責務をはじめから正しいところに配置することができません。今ではそうした状況においても、リファクタリングを適用して、以前に決定したことを変えることができます。
やはり設計時にはすべて適切に責務を切り分けるのは難しいということ。機能も付け足されていくし、適宜見直してリファクタリングしていくのがよさそう。
システムが発展していくにつれて、新たなクラスや責務の振り直しが必要になります。ある週ではそうではなくなります。それが問題ではなくて、それについてなにもしないことが問題なのです。
ぐさり。めっちゃ刺さる。そうだよね。
第８章：データの再編成
- オブジェクトによるデータ値・配列の置き換え
- クラス・サブクラスによるタイプコードの置き換え
第９章：条件記述の単純化
- 条件記述の分解 ⇔ 条件記述の結合
- 重複した条件記述の断片の統合
- ガード節による入れ子条件記述の置き換え
- ポリモーフィズムによる条件記述の置き換え
第１０章：メソッド呼び出しの単純化
- メソッド名の変更
- パラメータの追加 ⇔ パラメータの削除
- 問い合わせと更新の分離
- オブジェクトそのものの受け渡し
- パラメータオブジェクトの導入
- Factory Methodによるコンストラクタの置き換え
第１１章：継承の取り扱い
- フィールド・メソッド・コンストラクタの引き上げ ⇔ フィールド・メソッドの引き下げ
- サブクラス・スーパークラス・インターフェースの抽出
- Template Methodの形成
第１２章：大きなリファクタリング
手続き的な設計からオブジェクト指向への変換
まさに、いまいまリファクタリングでやりたいのはこれだな。MVCでクラスを使った書き方しているけど、複雑な処理が手続き的な形で記述されていて、すべてを読み込まないと仕様が理解出来ない。もっとオブジェクト指向の利点を活かして責務をいい感じに分けながら設計し直したいな。
全体を通じて
面白かった。普段これ自分も考えてるなーってものや、あっ全然このパターンは考えてことなかったやってもの。あとは、自分はこれはやりすぎなんじゃないかなーって思うものまでいろいろあったけど、様々なパターンをたくさん集めてまとめてあるっていうのはなかなか今後も参照できそうな本だなと思った。
あとは、自分たちのコードのリファクタリングの時に、ここでは○○のパターンを使ってこうリファクタリングして見ようみたいな会話ができれば結構スムーズにチームでリファクタリングが進みそう。