はじめに
ほぼ個人的な読書メモになります
「リファクタリング」 Martin Fowler著 児玉公信ほか訳
大まかに以下の流れで展開される
- 概論
- 不吉な臭い（リファクタリングされるべきコードの特徴）
- リファクタリングカタログ（小さいもの -> 大きいものの順）
- 実際にリファクタリングをするにあたって
わかったこと
リファクタリングについて
オブジェクト指向のリファクタリングについて知見が深まった。
私は何でもかんでも細かくクラス化すればリファクタリングになると思っていた（手続き型の長ったらしいコードが悪だと思っていたし、実際それは正しい）。他、一時変数のインライン化や仲介人の除去など、私が持っていたイメージとは逆のことも、その逆（＝私にイメージするリファクタリング）と同じ粒度で記述されていた。
とりわけ、今回、クラスを統合するなどクラス化しないという選択肢がある、と知った。
ちょうど本書の後半に差し掛かったタイミングで、私が関わっているソフトウェア開発リファクタリングを行う場面が訪れた。そこで、JavaのCollectionをクラス化してカプセル化する設計を思いついた。しかしこの変更はレビュワーにリジェクトされてしまった。
ポイントは2つ
- そのクラスは全くCollectionのメソッドを委譲している（されている？）だけだった
- 現代のJavaにおいてCollectionは高機能で、ラップされる必要性は低い
まさに「クラス化しない」場面に出会ったわけである。本書を読んでいたタイミングと重なって、非常に印象的な体験になった。
GoFパターンについて学んだ直後であったので、その知識が理解を促進した（特にState/Strategy pattern）
だが実際にやってみルナら難しそうだと思った（他のリファクタもそうだが...）
その他について
書かれた当時の筆者らを取り巻く情勢も知れた。またオブジェクト指向が研究室レベルだった頃は興味深い。
リファクタリングは可能なところまで行って、コードが壊れてしまうようになれば（頑張ればできそうでも）無理せずそこで止める、というのも新しい
テストがないと始まらない。テスト大事
リファクタリングを敬遠すると、リファクタリングを行った場合よりも損をする場合が多い
最近だとリファクタリングツールが高機能化しているので、簡単なリファクタリングは秒でできそう。確かにシグネチャの変更などは日常的に行っており、IDE任せですぐ簡単にできる、例外もあるようだが、Kotlinは強く型付けされているのでまだその例に出会ったことはない。
わからなかったこと
- 自己カプセル化はリファクタリング中にだけ行われるもので、リファクタリングの終了に伴って除去されるもの？自己カプセル化を残しておくメリットは何か？
- 表明（assert）は今でも普通に使われている？例外に取って代わられそうだと思った。