【書評】レガシーコード改善ガイド

読書感想文です。

概要

導入は既存のコードを修正するにはどうするかという流れですが、内容の8割近くはテストの話です。 斬新な内容という感じではありませんが、普段何気なくやっている様々なリファクタリング手法を定義し、名前付けてくれる本です。 例えば大きめな既存メソッドに新規処理を追加する場合、既存メソッドには新規メソッドだけを追加し、新規メソッドの内部に新しい処理をまとめる。こうすることで変更箇所を一つにまとめてしまう、このやり方をスプラウトメソッドと呼ぶ、などです。

グッときたところ

• 処理同士がつながる「接合部」を意識することでテストのための構造が見えてくる
• private メソッドをテストしたいのなら、そもそも public であるべきものかもしれない
• リフレクションは便利だが、テスタビリティを考慮した実装を保つという観点は満たされない
• sealed や final は控えることを推奨する、テスト用に継承クラスを作れなくなる
• 状態を変更するコマンド、状態を変更せず値を返すクエリ、この二つの役割分担を意識する
• システムのストーリーを話す：アーキテクチャや相互作用を誰かに話しながら整理することで、設計の本質部分を見いだしていく
• メソッド抽出においては int → double のような型変換は特に気をつける
• あまりにも巨大なメソッドなら、それだけで一つのクラスに抽出するという手段がある

雑感

自分が private メソッドをテストするときはよくリフレクションを使っているため、テストのためのリファクタリングを通して構造を見直すべきという話は耳が痛いところです。 とは言え、例えば sealed によって不用意な継承クラスを作って欲しくないという意図を宣言し、長期で見て実装が複雑にならないようにするという運用も当然あり得るわけで、どの程度テストのためのアーキテクチャにすべきかは常に考えていきたいところです。