Katsuyaのひとりごと。

怠惰で短気で傲慢なつぶやきを

読書記録 - 『レガシーコード改善ガイド』

読んだ本

www.amazon.co.jp

動機 - 既存のコードを改修する際のヒントが欲しくて読もうと思った

本書を読む動機は以下のような感じです。

  • 『レガシーコードからの脱却』が比較的チームレベルでの取り組みとかマインドセット的なレイヤを扱ってた覚えがあり、1人からでもできる範囲のプラクティス系の本を読みたくて本書にたどり着きました。
  • あとは今自分が既存のコードをベースに新機能追加や改修をする状況に置かれているので、きっとすぐに役に立つ情報が書かれているに違いないって思ったのもあります。

ぶっちゃけタイトルに釣られて買った部分が大きいですね...笑

www.amazon.co.jp

構成 - 第2部のFAQ形式の問題解決事例集がメイン

本書は3部構成です。

第1部(1-5章)は導入が書かれていて、ソフトウェアを変更する理由、変更手順、変更する上で覚えておくべき重要な概念やツールが紹介されています。

第2部(6-24章)が本書のメインパートです。 コードを変更しようとする際によく遭遇する具体的な問題を起点としてFAQ形式で書かれています。 全部の章ではないですがだいたい以下のような構成だったかと。

  1. 問題点の整理
  2. テストコードの書き方
  3. リファクタリングの適用

第3部(25章のみ)はリファクタリングレシピが列挙されています。 多くはファウラーの『リファクタリング』で書かれていたのと似たようなレシピだったと思います。

www.amazon.co.jp

要点 - 挙動理解にも改修作業にもまずテストを書くことから

印象に残ったことをいくつか書きます。

  • 影響調査のために処理を図に起こすこと
    • 図にするのは至極当たり前のことだとは思うけど、圧倒的に自分には足りないところだと感じました。
  • 試行リファクタリング
    • 自分はコードリーディングする際に後で破棄するリファクタリングをよくしていて、それと同じことが挙動理解のためのプラクティスとして紹介されていました。
  • 第2部ではどうやってテストを書くかに着眼点を置いてること
  • タイトルに「改善ガイド」って書かれてるからてっきり改善それ自体のプラクティスが多く書かれていると思っていたけど、どちらかというと改善のためにいかにしてテストコードを書くかって方に著者の熱意を感じました。

自分の中での本書の立ち位置・感想

コードの改修作業に取り掛かる前に本書の第2部のFAQから似たような事例を参考にして、問題点の洗い出し・整理をするのが良いかもと思いました。 それ以降リファクタリングが必要な場合は第3部を読むか『リファクタリング』のレシピを参考にするとか。

第2部の各章のタイトルはどれも「〇〇ができません」とか「〇〇をするにはどうしたらいいですか?」って感じなんですが、全部「うわ...心当たりある...」ってものばかりでした。 日頃の抱いてるモヤモヤや誰かにぶつけたい疑念をまさに本書が払拭してくれるかもと期待できるような章タイトルになっているなぁと。

どの章も具体例としてコードが書かれていて、何にどう困っていてどうすればもっと良い構造になるのかが細かく書かれているので、読んでいて理解できないって点は無いと思います。

次のアクション

ファウラーの『リファクタリング』は大学の研究室で読んだきりだったので、買って手元に置いておきたいと思いました。

改修タスクやるときにユニットテストが書かれていない長大サービスクラスとかに手を入れる必要とかが往々にしてあるので、本書に書かれてるようなテストコードの書き方を1つ実践してみたいです。