【読書ログ】リファクタリング-既存のコードを安全に改善する-第2版

読む理由

• 業務でリファクタリングしたいけどバグを生み出しそうで二の足を踏んでいる
• ひまじんプログラマーの週末エンジニアリングレッスンでおすすめされており，サンプルコードが第1版ではJavaだったのが第2版でJavaScriptになったと知った

はじめに

• 「リファクタリングとはソフトウェアの外部の振る舞いを保ったままで，内部の構造を改善していく作業」（p.xiv）
• リファクタリングによって，設計→実装というこれまでのフローが，設計と実装を行き来するようになる．全工程で設計が行われ，徐々によりよい設計に導かれる（p.x）

1章

• 機能追加の前に機能追加しやすいようにリファクタリングしよう！
• リファクタリングの前にテストコードの追加は必須
• ローカル変数が少ないほうがローカルスコープが減って後に関数として抽出しやすい．関数を実行する回数がパフォーマンスに影響を与えることは少ない．もしもパフォーマンスに影響があってもリファクタリングを続ける．その後にパフォーマンスの最適化をする．
  • かっこいい
• formatAsUSDという関数名は長すぎ．usdでいい．
  • ほんとに...？という気持ち
• 良いコードかどうか = 変更が容易なコードか

感想

1章の内容は4章で紹介されるリファクタリングメソッドをサンプルコードに適用すること．紙の本だとリファクタリング前後の差分が分かりづらいかも．個人的には4章の内容を見てからのほうが読みやすそうだと感じた．

2章

• リファクタリングと機能追加は同時に行わない（「リファクタリングの帽子」と「機能追加の帽子」をかぶり直す）
  • 「帽子」のメタファーがわかりやすい
• よくないコードを見つけたらその都度リファクタリングするのはもちろん、よいコードもリファクタリングが必要になることがある。最適化されたよいコードは機能追加などの変更時にリファクタリングの対象になる。
• リファクタリングが開発者のための作業でありビジネス価値を産まないというのは誤解。リファクタリングによってコードがよい状態（変更に強い、可読性が高いなど）になり新機能の開発スピードが上がり、結果的に価値を生み出す。ビジネス側に受け入れられなかった場合は黙ってリファクタリングする。
  • 黙ってリファクタリングすることに関しては著者も「問題発言のよう」と触れていた
• （リファクタリングではなくパフォーマンスの関連で）推測しないで計測する

感想

リファクタリングとは何か、その目的・効果について体験談も踏まえながらひたすら語る章。各節はMECEではなく「この3つの目的です！」みたいな書き方はされていないので、ざっと目を通して自分なりにまとめる読み方がいい感じかも。

3章

感想

• オブジェクト指向であることを前提に書かれている箇所が多い（第1版がJavaだからそれはそう）
• アンチパターンと解決策の組合せが書かれている。解決策は筆者が命名した手法で書かれており、その手法の具体的な内容は4章以降に書かれている。先にそっちを読んでから戻ってきたほうがいいかも？

4章

• 自動テストはリファクタリングに不可欠として、自動テストについてMochaとChaiを例にコードベースで解説する章
• スタブデータを共通化してもバグになる（テスト後に初期化を忘れるなど）ことがあるから、テストは冗長に書いていい
• バグレポートを受け取ったら自動テストのテストケースを追加することから始めましょう

感想

• 何かしらのツールで自動テストを書いたことがあれば知っていそうな内容ではある。当時は自動テストそのものが画期的だったのだろうという推測。

5章

• これからリファクタリング手法をこの形式で解説していくよーって宣言する章
• 筆者はこのリファクタリング手法のリストを「カタログ」と読んでいる

6章以降

リファクタリングの手法がひたすら列挙されている。筆者が心掛けている細かい手順も書かれているので結構ボリュームがある。詳細は書かずに共通して心がけるべきことや印象的な手法だけ書こうと思う。

• 関数のスコープを移動させるときはコピーして一時的な別名をつけることで、変更を戻しやすくする
  • 直前でcommitしておいてIDEで静的解析すれば戻すことも変更が必要な箇所もわかるので、ここまで細かい手順を踏まなくてもいいかも
• 絶対的な方針はないので、変更しやすくしておいて最適化を繰り返す。最適化したコードも仕様の変更等によってあるべき姿が変わる。